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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3be548bf-aee4-46ab-bcbf-15bf629b24da@os.amperecomputing.com>
Date: Thu, 19 Jun 2025 15:10:15 +0530
From: Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>
To: Marc Zyngier <maz@...nel.org>
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


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

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

-- 
Thanks,
Gk