Re: [RFC PATCH v2 0/9] KVM: Enable Nested Virt selftests

[Ganapatrao Kulkarni]

Hi Marc,

On 6/23/2025 7:41 PM, Marc Zyngier wrote:
> On Mon, 23 Jun 2025 11:31:32 +0100,
> Ganapatrao Kulkarni <gankulkarni@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On 6/19/2025 5:15 PM, Marc Zyngier wrote:
> > > >    >
> > > > > Also, running EL2 is the least of our worries, because that's pretty
> > > > > easy to deal with. It is running at EL1/0 when EL2 is present that is
> > > > > interesting, and I see no coverage on that front.
> > > >
> > > > Sorry, I did not get this comment fully.
> > > > When we run selftest on Host with -g option, the guest code will run in vEL2 as L1.
> > > > This is implemented as per comment in V1.
> > > >
> > > > When we run same selftest from L1 shell, then guest_code will be running in EL0/1 like running from L0.
> > >
> > > What good does this bring us if we need to boot a full guest OS to run
> > > tests? What we need is synthetic tests that implement the whole stack:
> > >
> > > - L1 guest hypervisor
> > > - L2 guest hypervisor
> > > - L2 guest
> > > - L3 guest hypervisor
> > > - L3 guest
> > > - [...]
> >
> > IIUC, selftest leverages host OS support and uses various IOCTLs to
> > support the guest_code run. Are you saying to implement all this
> > again (without OS help) in guest_code to run it as hypervisor and
> > launch guest_code2 as NestedVM?.
>
> The whole point of having small selftests is to run something that is
> simpler several orders of magnitude simpler than the full blown
> OS/hypervisor. So indeed, I'm asking for selftests that build chains
> of guests up to some level and verify that the nesting, as described
> in the architecture, works correctly.

Do you see value in the patches as they are, without the changes to support the bare-metal hypervisor in guest, or will you only consider them if they are first reworked to support the recursive guests?

--
Thanks,
Gk