| Message ID | 20220215031642.1691873-1-npiggin@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ppc: nested KVM HV for spapr virtual hypervisor | expand |
On 2/15/22 04:16, Nicholas Piggin wrote: > Here is the rollup of patches in much better shape since the RFC. > I include the 2 first ones unchanged from independent submission > just to be clear that this series requires them. > > Thanks Cedric and Fabiano for wading through my poor quality RFC > code, very good changes suggested and I hope I got most of them > and this one is easier to follow. This is in good shape and functional. I will try to propose a small buildroot environment for it, so that we don't have to start a full distro to test. I would like to talk about the naming. KVM-HV is I think "reserved" to the PowerNV platform (baremetal). We also have KVM-PR which runs KVM guests on various platforms, including pseries. How can we call this yet another KVM PPC implementation ? Thanks, C. > > Thanks, > Nick > > Nicholas Piggin (9): > target/ppc: raise HV interrupts for partition table entry problems > spapr: prevent hdec timer being set up under virtual hypervisor > ppc: allow the hdecr timer to be created/destroyed > target/ppc: add vhyp addressing mode helper for radix MMU > target/ppc: make vhyp get_pate method take lpid and return success > target/ppc: add helper for books vhyp hypercall handler > target/ppc: Add powerpc_reset_excp_state helper > target/ppc: Introduce a vhyp framework for nested HV support > spapr: implement nested-hv capability for the virtual hypervisor > > hw/ppc/pegasos2.c | 6 + > hw/ppc/ppc.c | 22 ++- > hw/ppc/spapr.c | 41 ++++- > hw/ppc/spapr_caps.c | 11 +- > hw/ppc/spapr_cpu_core.c | 6 +- > hw/ppc/spapr_hcall.c | 321 +++++++++++++++++++++++++++++++++++++++ > include/hw/ppc/ppc.h | 3 + > include/hw/ppc/spapr.h | 74 ++++++++- > target/ppc/cpu.h | 8 +- > target/ppc/excp_helper.c | 129 ++++++++++++---- > target/ppc/mmu-radix64.c | 41 ++++- > 11 files changed, 610 insertions(+), 52 deletions(-) >
On 2/15/22 15:33, Cédric Le Goater wrote: > On 2/15/22 04:16, Nicholas Piggin wrote: >> Here is the rollup of patches in much better shape since the RFC. >> I include the 2 first ones unchanged from independent submission >> just to be clear that this series requires them. >> >> Thanks Cedric and Fabiano for wading through my poor quality RFC >> code, very good changes suggested and I hope I got most of them >> and this one is easier to follow. > > This is in good shape and functional. I will try to propose a small > buildroot environment for it, so that we don't have to start a full > distro to test. > > I would like to talk about the naming. KVM-HV is I think "reserved" > to the PowerNV platform (baremetal). We also have KVM-PR which runs > KVM guests on various platforms, including pseries. > > How can we call this yet another KVM PPC implementation ? Do we need a new name? I believe Nick uses the stock kvm_hv kernel module in this implementation. If we want a name to differ between the different KVM-HV usages, well, I'd suggest KVM-EHV (Emulated HV) or KVM-NHV (Nested HV) or KVM-VHV (Virtual HV) or anything that suggests that this is a different flavor of using KVM-HV. Thanks, Daniel > > Thanks, > > C. > >> >> Thanks, >> Nick >> >> Nicholas Piggin (9): >> target/ppc: raise HV interrupts for partition table entry problems >> spapr: prevent hdec timer being set up under virtual hypervisor >> ppc: allow the hdecr timer to be created/destroyed >> target/ppc: add vhyp addressing mode helper for radix MMU >> target/ppc: make vhyp get_pate method take lpid and return success >> target/ppc: add helper for books vhyp hypercall handler >> target/ppc: Add powerpc_reset_excp_state helper >> target/ppc: Introduce a vhyp framework for nested HV support >> spapr: implement nested-hv capability for the virtual hypervisor >> >> hw/ppc/pegasos2.c | 6 + >> hw/ppc/ppc.c | 22 ++- >> hw/ppc/spapr.c | 41 ++++- >> hw/ppc/spapr_caps.c | 11 +- >> hw/ppc/spapr_cpu_core.c | 6 +- >> hw/ppc/spapr_hcall.c | 321 +++++++++++++++++++++++++++++++++++++++ >> include/hw/ppc/ppc.h | 3 + >> include/hw/ppc/spapr.h | 74 ++++++++- >> target/ppc/cpu.h | 8 +- >> target/ppc/excp_helper.c | 129 ++++++++++++---- >> target/ppc/mmu-radix64.c | 41 ++++- >> 11 files changed, 610 insertions(+), 52 deletions(-) >> > >
Daniel Henrique Barboza <danielhb413@gmail.com> writes: > On 2/15/22 15:33, Cédric Le Goater wrote: >> On 2/15/22 04:16, Nicholas Piggin wrote: >>> Here is the rollup of patches in much better shape since the RFC. >>> I include the 2 first ones unchanged from independent submission >>> just to be clear that this series requires them. >>> >>> Thanks Cedric and Fabiano for wading through my poor quality RFC >>> code, very good changes suggested and I hope I got most of them >>> and this one is easier to follow. >> >> This is in good shape and functional. I will try to propose a small >> buildroot environment for it, so that we don't have to start a full >> distro to test. >> >> I would like to talk about the naming. KVM-HV is I think "reserved" >> to the PowerNV platform (baremetal). We also have KVM-PR which runs >> KVM guests on various platforms, including pseries. >> >> How can we call this yet another KVM PPC implementation ? > > Do we need a new name? I believe Nick uses the stock kvm_hv kernel module in this > implementation. > > If we want a name to differ between the different KVM-HV usages, well, I'd suggest > KVM-EHV (Emulated HV) or KVM-NHV (Nested HV) or KVM-VHV (Virtual HV) or anything > that suggests that this is a different flavor of using KVM-HV. I'd say it's imperative to have a clear indication that this is TCG. Otherwise we'll have people trying to weird stuff with it and complaining that Nested KVM is bugged. Some ideas: Emulated Nested KVM Emulated Nested HV Nested TCG The first one is perhaps more accurate, but we'd end up having "kvm" mentioned in TCG code and that is super confusing.
Excerpts from Fabiano Rosas's message of February 16, 2022 5:20 am: > Daniel Henrique Barboza <danielhb413@gmail.com> writes: > >> On 2/15/22 15:33, Cédric Le Goater wrote: >>> On 2/15/22 04:16, Nicholas Piggin wrote: >>>> Here is the rollup of patches in much better shape since the RFC. >>>> I include the 2 first ones unchanged from independent submission >>>> just to be clear that this series requires them. >>>> >>>> Thanks Cedric and Fabiano for wading through my poor quality RFC >>>> code, very good changes suggested and I hope I got most of them >>>> and this one is easier to follow. >>> >>> This is in good shape and functional. I will try to propose a small >>> buildroot environment for it, so that we don't have to start a full >>> distro to test. >>> >>> I would like to talk about the naming. KVM-HV is I think "reserved" >>> to the PowerNV platform (baremetal). We also have KVM-PR which runs >>> KVM guests on various platforms, including pseries. >>> >>> How can we call this yet another KVM PPC implementation ? >> >> Do we need a new name? I believe Nick uses the stock kvm_hv kernel module in this >> implementation. >> >> If we want a name to differ between the different KVM-HV usages, well, I'd suggest >> KVM-EHV (Emulated HV) or KVM-NHV (Nested HV) or KVM-VHV (Virtual HV) or anything >> that suggests that this is a different flavor of using KVM-HV. > > I'd say it's imperative to have a clear indication that this is > TCG. Otherwise we'll have people trying to weird stuff with it and > complaining that Nested KVM is bugged. Difficult to convey that in the L2 I think, but that is the case no matter what we call it in the L0 AFAIKS. > Some ideas: > > Emulated Nested KVM > Emulated Nested HV > Nested TCG > > The first one is perhaps more accurate, but we'd end up having "kvm" > mentioned in TCG code and that is super confusing. It provides the "nested HV" hypervisor API so it can support guests that use the nested HV KVM backend. The matter between TCG and real metal is on top of that -- the user knows TCG is emulated. So, not sure how to go. We could remove the KVM name. The cap itself is just called nested-hv and that's what KVM uses. I think KVM here was added in the description just so you would konw that KVM can be run on it. Thanks, Nick