linux-kernel - Re: [PATCH] KVM: arm64: nv: Set ISTATUS for emulated timers, If timer expired

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: <8da22249-eedb-477b-98d8-f50dee56f1f7@redhat.com>
Date: Mon, 10 Feb 2025 19:26:48 +0100
From: Eric Auger <eauger@...hat.com>
To: Marc Zyngier <maz@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>
Cc: Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>,
 kvmarm <kvmarm@...ts.linux.dev>, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, christoffer.dall@....com,
 suzuki.poulose@....com, will@...nel.org, catalin.marinas@....com,
 coltonlewis@...gle.com, joey.gouly@....com, yuzenghui@...wei.com,
 darren@...amperecomputing.com, vishnu@...amperecomputing.com
Subject: Re: [PATCH] KVM: arm64: nv: Set ISTATUS for emulated timers, If timer
 expired

Hi Marc,

On 2/7/25 7:38 PM, Marc Zyngier wrote:
> On Fri, 07 Feb 2025 18:09:58 +0000,
> Oliver Upton <oliver.upton@...ux.dev> wrote:
>>
>> Hey,
>>
>> On Fri, Feb 07, 2025 at 05:45:33PM +0000, Marc Zyngier wrote:
>>> I found at least one issue that could fail the migration. Before the
>>> VM starts running, we limit the feature set to the subset we actually
>>> support with NV.
>>>
>>> By doing this, we also change the value of IDreg fields that are not
>>> writable, because they describe features that we don't support.
>>> Obviously, that fails on restore.
>>>
>>> I need to have a think...
>>
>> We spoke about this a while ago (and I forgot til now), but I was
>> wondering if we could use vCPU feature flags to describe NV, including
>> the selection between FEAT_E2H0 and FEAT_VHE.
>>
>> I think this might match userspace expectations a bit more closely where
>> the state of the ID registers after init gives the actual feature set
>> supported by the VM.
> 
> I'm not sure that's enough. Let me give you an example:
> 
> My host has FEAT_XNX, described in ID_AA64MMFR1_EL1.XNX. For whatever
> reason, we don't allow this field to be written to, even out of NV
> context. This is odd, because for an EL1 VM, this field means nothing
> at all.
So the curprit fields for me look like

- ID_AA64MMFR1_EL1.XNX
- ID_AA64DFR0_EL1.DoubleLock
- ID_AA64PFR0_EL1.RAS

This is still based on your nv-next branch from Jan 9
https://github.com/eauger/linux/tree/nv_next_jan9_2025

Eric
> 
> However, we don't yet support FEAT_XNX with NV (it requires some extra
> surgery in the S2 walker, in the S2 shadowing code and in AT).
> 
> How would you manage this field if you had a vcpu flag saying E2H0 or
> not? I don't think it helps, at least not in that particular case. It
> may help for some things, but not all.
> 
> It feels that we need to define the field limit (and what is writable
> or not) based on the NV/!NV support, and maybe E2H0/VHE as well.
> 
> This is getting complicated...
> 
> 	M.
>