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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <86ecu48riv.wl-maz@kernel.org>
Date: Fri, 25 Jul 2025 11:59:52 +0100
From: Marc Zyngier <maz@...nel.org>
To: Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>
Cc: Eric Auger <eauger@...hat.com>,
	linux-arm-kernel@...ts.infradead.org,
	kvmarm@...ts.linux.dev,
	linux-kselftest@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	oliver.upton@...ux.dev,
	joey.gouly@....com,
	suzuki.poulose@....com,
	yuzenghui@...wei.com,
	seanjc@...gle.com,
	darren@...amperecomputing.com
Subject: Re: [RFC PATCH v2 0/9] KVM: Enable Nested Virt selftests

On Fri, 25 Jul 2025 11:01:05 +0100,
Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com> wrote:
> 
> 
> Hi Marc,
> 
> On 6/23/2025 7:41 PM, Marc Zyngier wrote:
> > On Mon, 23 Jun 2025 11:31:32 +0100,
> > Ganapatrao Kulkarni <gankulkarni@...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?

Running existing tests at EL2 may an interesting goal, but the way
you've gone about it is really wrong. These tests are not about
"nested", they are about running at EL2. So getting rid of all the
"nested" nonsense in patch #1 and focusing on the *two* flavours of
EL2 would be a good start.

Also, EL2 tests shouldn't be optional. If EL2 is available, the test
should run, without any option, and things like

+	if (is_nested)
+		vm = nv_vm_create_with_vcpus_gic(1, &vcpu, &gic_fd, guest_main);
+	else
+		vm = vm_create_with_one_vcpu(&vcpu, guest_main);

are just non-starters. You just need to either get rid of the whole
vm_create_with_one_vcpu() nonsense, or teach it to take an execution
context.

But the real NV tests are not optional either. They need to happen,
and I don't have the confidence that they will if I agree to what you
are suggesting. Because it's been months since I asked for these
things, and not much has happened in the interval.

	M.

-- 
Without deviation from the norm, progress is not possible.