[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 8/9] target/ppc: Introduce a vhyp framework for nested HV sup

From: Nicholas Piggin
Subject: Re: [PATCH 8/9] target/ppc: Introduce a vhyp framework for nested HV support
Date: Wed, 16 Feb 2022 10:49:17 +1000

Excerpts from BALATON Zoltan's message of February 16, 2022 5:19 am:
> On Tue, 15 Feb 2022, Cédric Le Goater wrote:
>> On 2/15/22 04:16, Nicholas Piggin wrote:
>>> Introduce virtual hypervisor methods that can support a "Nested KVM HV"
>>> implementation using the bare metal 2-level radix MMU, and using HV
>>> exceptions to return from H_ENTER_NESTED (rather than cause interrupts).
>>> HV exceptions can now be raised in the TCG spapr machine when running a
>>> nested KVM HV guest. The main ones are the lev==1 syscall, the hdecr,
>>> hdsi and hisi, hv fu, and hv emu, and h_virt external interrupts.
>>> HV exceptions are intercepted in the exception handler code and instead
>>> of causing interrupts in the guest and switching the machine to HV mode,
>>> they go to the vhyp where it may exit the H_ENTER_NESTED hcall with the
>>> interrupt vector numer as return value as required by the hcall API.
>>> Address translation is provided by the 2-level page table walker that is
>>> implemented for the bare metal radix MMU. The partition scope page table
>>> is pointed to the L1's partition scope by the get_pate vhc method.
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>>   hw/ppc/pegasos2.c        |  6 ++++
>>>   hw/ppc/spapr.c           |  6 ++++
>>>   target/ppc/cpu.h         |  2 ++
>>>   target/ppc/excp_helper.c | 76 ++++++++++++++++++++++++++++++++++------
>>>   target/ppc/mmu-radix64.c | 15 ++++++--
>>>   5 files changed, 92 insertions(+), 13 deletions(-)
>>> diff --git a/hw/ppc/pegasos2.c b/hw/ppc/pegasos2.c
>>> index 298e6b93e2..d45008ac71 100644
>>> --- a/hw/ppc/pegasos2.c
>>> +++ b/hw/ppc/pegasos2.c
>>> @@ -449,6 +449,11 @@ static target_ulong pegasos2_rtas(PowerPCCPU *cpu, 
>>> Pegasos2MachineState *pm,
>>>       }
>>>   }
>>>   +static bool pegasos2_cpu_in_nested(PowerPCCPU *cpu)
>>> +{
>>> +    return false;
>>> +}
>>> +
>>>   static void pegasos2_hypercall(PPCVirtualHypervisor *vhyp, PowerPCCPU 
>>> *cpu)
>>>   {
>>>       Pegasos2MachineState *pm = PEGASOS2_MACHINE(vhyp);
>>> @@ -504,6 +509,7 @@ static void pegasos2_machine_class_init(ObjectClass 
>>> *oc, void *data)
>>>       mc->default_ram_id = "pegasos2.ram";
>>>       mc->default_ram_size = 512 * MiB;
>>>   +    vhc->cpu_in_nested = pegasos2_cpu_in_nested;
>>>       vhc->hypercall = pegasos2_hypercall;
>>>       vhc->cpu_exec_enter = vhyp_nop;
>>>       vhc->cpu_exec_exit = vhyp_nop;
>> I don't think you need to worry about the pegasos2 machine as it only
>> implements a few of the PPCVirtualHypervisorClass handlers and it can
>> not run any of these virtualization features. I would drop this part.
> I don't know anything about HV and running it nested but I'm sure pegasos2 
> does not run with it as the hardware does not have HV (or radix MMU which 
> is mentioned in the commit message above) and I've only used vhyp here to 
> avoid having to modify vof and be able to use the same vof.bin that we 
> have. This was the simplest way but it probably does not work with KVM 
> either so I agree that unless it's required to implement this method for 
> all machines using vhyp then this should not be needed for pegasos2. We 
> only really need hypercall to be able to use VOF which is needed for 
> booting OSes as the board firmware is not redistributable.
> If this gets in the way we could replace it with some other hypercall 
> method (there was some discussion during the review of the series adding 
> VOF support to pegasos2, we could support MOL OSI or some own solution 
> instead) if VOF supported these, but I did not want to touch VOF so went 
> with the simplest working solution.

Thanks, if there is a problem we can solve it one way or another. Don't
worry about it for now but when reviews are happy I might just need help
to test it doesn't interfere with your machine.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]