Message ID | 20230605064848.12319-1-jpn@linux.vnet.ibm.com |
---|---|
Headers | show |
Series | KVM: PPC: Nested PAPR guests | expand |
On Mon Jun 5, 2023 at 4:48 PM AEST, Jordan Niethe wrote: > There is existing support for nested guests on powernv hosts however the > hcall interface this uses is not support by other PAPR hosts. I kind of liked it being called nested-HV v1 and v2 APIs as short and to the point, but I suppose that's ambiguous with version 2 of the v1 API, so papr is okay. What's the old API called in this scheme, then? "Existing API" is not great after patches go upstream. And, you've probably explained it pretty well but slightly more of a background first up could be helpful. E.g., A nested-HV API for PAPR has been developed based on the KVM-specific nested-HV API that is upstream in Linux/KVM and QEMU. The PAPR API had to break compatibility to accommodate implementation in other hypervisors and partitioning firmware. And key overall differences The control flow and interrupt processing between L0, L1, and L2 in the new PAPR API are conceptually unchanged. Where the old API is almost stateless, the PAPR API is stateful, with the L1 registering L2 virtual machines and vCPUs with the L0. Supervisor-privileged register switching duty is now the responsibility for the L0, which holds canonical L2 register state and handles all switching. This new register handling motivates the "getters and setters" wrappers ... Thanks, Nick
On Wed, Jun 7, 2023 at 3:54 PM Nicholas Piggin <npiggin@gmail.com> wrote: > > On Mon Jun 5, 2023 at 4:48 PM AEST, Jordan Niethe wrote: > > There is existing support for nested guests on powernv hosts however the > > hcall interface this uses is not support by other PAPR hosts. > > I kind of liked it being called nested-HV v1 and v2 APIs as short and > to the point, but I suppose that's ambiguous with version 2 of the v1 > API, so papr is okay. What's the old API called in this scheme, then? > "Existing API" is not great after patches go upstream. Yes I was trying for a more descriptive name but it is just more confusing and I'm struggling for a better alternative. In the next revision I'll use v1 and v2. For version 2 of v1 we now call it v1.2 or something like that? > > And, you've probably explained it pretty well but slightly more of > a background first up could be helpful. E.g., > > A nested-HV API for PAPR has been developed based on the KVM-specific > nested-HV API that is upstream in Linux/KVM and QEMU. The PAPR API > had to break compatibility to accommodate implementation in other > hypervisors and partitioning firmware. > > And key overall differences > > The control flow and interrupt processing between L0, L1, and L2 > in the new PAPR API are conceptually unchanged. Where the old API > is almost stateless, the PAPR API is stateful, with the L1 registering > L2 virtual machines and vCPUs with the L0. Supervisor-privileged > register switching duty is now the responsibility for the L0, which > holds canonical L2 register state and handles all switching. This > new register handling motivates the "getters and setters" wrappers > ... I'll include something along those lines. Thanks, Jordan > > Thanks, > Nick >