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: <87r0441e6v.wl-maz@kernel.org>
Date: Tue, 11 Feb 2025 19:20:08 +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

Right, that more or less matches what I see locally.

I adopted the following scheme:

- On top of the existing KVM_ARM_VCPU_HAS_EL2, we have a new
  KVM_ARM_VCPU_HAS_EL2_E2H0, which is only valid when the former is
  also set, and force the whole VM in E2H==0 mode (that's Oliver's
  idea above)

- The NV view of the ID registers is enforced at the point where we
  compute the limit values via the ID reg reset helper, instead of the
  post-init repainting

- Neither of ID_AA64MMFR1_EL1.VH or ID_AA64MMFR4_EL1.E2H0 are writable
  at all

- Only ID_AA64MMFR4_EL1.NV_frac is writable

The result is fairly small, but is of course quite an ABI breakage,
and I'm more than happy not to have merged it sooner. Maybe I should
wait another couple of years! ;-)

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

Yeah, that's getting old now, specially given the nature of the bug
fixes that have been added.

I'll try to rebase everything on -rc2 with the latest fixes and the
new ABI by the end of the week, and we will take it from there.

Thanks,

	M.

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