qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: "BALATON Zoltan" <balaton@eik.bme.hu>, "Cédric Le Goater" <clg@kaod.org>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	Fabiano Rosas <farosas@linux.ibm.com>
Subject: Re: [PATCH 8/9] target/ppc: Introduce a vhyp framework for nested HV support
Date: Wed, 16 Feb 2022 10:49:17 +1000	[thread overview]
Message-ID: <1644972436.l3db0ngdqs.astroid@bobo.none> (raw)
In-Reply-To: <2f25a033-aaf8-ba88-1d9f-81745ffba392@eik.bme.hu>

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.

Thanks,
Nick


  reply	other threads:[~2022-02-16  0:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15  3:16 [PATCH 0/9] ppc: nested KVM HV for spapr virtual hypervisor Nicholas Piggin
2022-02-15  3:16 ` [PATCH 1/9] target/ppc: raise HV interrupts for partition table entry problems Nicholas Piggin
2022-02-15  8:29   ` Cédric Le Goater
2022-02-15  3:16 ` [PATCH 2/9] spapr: prevent hdec timer being set up under virtual hypervisor Nicholas Piggin
2022-02-15 18:34   ` Cédric Le Goater
2022-02-15  3:16 ` [PATCH 3/9] ppc: allow the hdecr timer to be created/destroyed Nicholas Piggin
2022-02-15 18:36   ` Cédric Le Goater
2022-02-16  0:36     ` Nicholas Piggin
2022-02-15  3:16 ` [PATCH 4/9] target/ppc: add vhyp addressing mode helper for radix MMU Nicholas Piggin
2022-02-15 10:01   ` Cédric Le Goater
2022-02-15  3:16 ` [PATCH 5/9] target/ppc: make vhyp get_pate method take lpid and return success Nicholas Piggin
2022-02-15 10:03   ` Cédric Le Goater
2022-02-15  3:16 ` [PATCH 6/9] target/ppc: add helper for books vhyp hypercall handler Nicholas Piggin
2022-02-15 10:04   ` Cédric Le Goater
2022-02-15  3:16 ` [PATCH 7/9] target/ppc: Add powerpc_reset_excp_state helper Nicholas Piggin
2022-02-15 10:04   ` Cédric Le Goater
2022-02-15  3:16 ` [PATCH 8/9] target/ppc: Introduce a vhyp framework for nested HV support Nicholas Piggin
2022-02-15 15:59   ` Fabiano Rosas
2022-02-15 17:28   ` Cédric Le Goater
2022-02-15 19:19     ` BALATON Zoltan
2022-02-16  0:49       ` Nicholas Piggin [this message]
2022-02-15  3:16 ` [PATCH 9/9] spapr: implement nested-hv capability for the virtual hypervisor Nicholas Piggin
2022-02-15 16:01   ` Fabiano Rosas
2022-02-15 18:21   ` Cédric Le Goater
2022-02-16  1:16     ` Nicholas Piggin
2022-02-16 10:23       ` Cédric Le Goater
2022-02-15 18:33 ` [PATCH 0/9] ppc: nested KVM HV for spapr " Cédric Le Goater
2022-02-15 18:45   ` Daniel Henrique Barboza
2022-02-15 19:20     ` Fabiano Rosas
2022-02-16  9:09       ` Nicholas Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1644972436.l3db0ngdqs.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=balaton@eik.bme.hu \
    --cc=clg@kaod.org \
    --cc=farosas@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).