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: <86jz58c5ut.wl-maz@kernel.org>
Date: Thu, 19 Jun 2025 12:45:30 +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 Thu, 19 Jun 2025 10:40:15 +0100,
Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com> wrote:
> 
> 
> [Sorry for late reply]
> 
> On 5/29/2025 5:18 PM, Marc Zyngier wrote:
> > On Thu, 29 May 2025 11:29:58 +0100,
> > Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com> wrote:
> >> 
> >> 
> >> Hi Eric,
> >> 
> >> On 5/28/2025 6:58 PM, Eric Auger wrote:
> >>> Hi Ganapatrao,
> >>> 
> >>> On 5/12/25 12:52 PM, Ganapatrao Kulkarni wrote:
> >>>> This patch series makes the selftest work with NV enabled. The guest code
> >>>> is run in vEL2 instead of EL1. We add a command line option to enable
> >>>> testing of NV. The NV tests are disabled by default.
> >>> 
> >>> For commodity, I would add in the coverletter that for all tests
> >>> enhanced with vEL2 testing "-g 1" option shall be added to force that mode.
> >> 
> >> Sure, will do.
> >> 
> >>> 
> >>> I don't really get how you chose tests capable to run at vEL2 and
> >>> excluded others? Wouldn't it make sense to have a way to run all tests
> >>> in either mode?
> >> There is no selection as such. I have worked on around 50% of the tests and sent for the early review.
> >> Yes, almost all tests can/should run in vEL2 except few.
> > 
> > Define EL2. You are so far assuming a E2H RES1 guest, and I don't see
> > anything that is even trying E2H RES0. After all the complaining that
> 
> Sure, I will mention that default test code runs in EL2 with E2H enabled.
> The tests code is in vEL2 with E2H RES1 by default, since host is booted with VHE.

Sight... You are still confused with what KVM does. With NV, the host
is *always* VHE. The guest can be VHE (E2H RES1) or nVHE (E2H RES0).

> > E2H0 wasn't initially supported, this is a bit... disappointing.
> IIRC, I was mentioning about L1 switching between arch mmu table and guest mmu table(VMID 0).
> I don't remember why It was switching.

-ENOPARSE.

>  > 
> > 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
- [...]

This is *one* test. Not a test that runs in a guest. That's what I've
been asking since day one.

	M.

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