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

Ganapatrao Kulkarni gankulkarni at os.amperecomputing.com
Fri Jul 25 03:01:05 PDT 2025


Hi Marc,

On 6/23/2025 7:41 PM, Marc Zyngier wrote:
> On Mon, 23 Jun 2025 11:31:32 +0100,
> Ganapatrao Kulkarni <gankulkarni at os.amperecomputing.com> 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



More information about the linux-arm-kernel mailing list