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

Message-ID: <87tt8v14j2.wl-maz@kernel.org>
Date: Sat, 15 Feb 2025 17:50:09 +0000
From: Marc Zyngier <maz@...nel.org>
To: Eric Auger <eauger@...hat.com>
Cc: Oliver Upton <oliver.upton@...ux.dev>,
	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

On Mon, 10 Feb 2025 18:26:48 +0000,
Eric Auger <eauger@...hat.com> wrote:
> 
> 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

I have now pushed out a new nv-next branch with the new and improved
UAPI. I expect migration to work a bit better, or at least not to
explode on ID register restore. You will notice that things have
changed a bit (extra flag and cap for FEAT_E2H0), but nothing really
major.

Thanks,

	M.

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