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
next prev parent 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).