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.

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(-)

-- 
2.23.0

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