linux-kernel - Re: [PATCH v8 11/29] KVM: arm64: Document the KVM ABI for SME

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: <562a8b3e-b663-4588-8594-059874939749@sirena.org.uk>
Date: Thu, 27 Nov 2025 15:47:32 +0000
From: Mark Brown <broonie@...nel.org>
To: Peter Maydell <peter.maydell@...aro.org>
Cc: Marc Zyngier <maz@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>,
	Joey Gouly <joey.gouly@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Will Deacon <will@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>,
	Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>,
	Dave Martin <Dave.Martin@....com>, Fuad Tabba <tabba@...gle.com>,
	Mark Rutland <mark.rutland@....com>,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org,
	Eric Auger <eric.auger@...hat.com>
Subject: Re: [PATCH v8 11/29] KVM: arm64: Document the KVM ABI for SME

On Thu, Nov 27, 2025 at 03:06:50PM +0000, Peter Maydell wrote:
> On Mon, 24 Nov 2025 at 20:13, Mark Brown <broonie@...nel.org> wrote:

> > That was deliberate and I agree it is awkward, it was introduced as a
> > result of earlier review comments.  I had originally implemented an ABI
> > where the VL for the vector registers was the maximum of the SVE and SME
> > VLs but the feedback was that the ABI should instead follow what the
> > architecture does with the vector length and potentially presence of the
> > vector registers depending on the current streaming mode configuration.
> > It sounds like you would prefer something more like what was there
> > originally?

> Yes, that's what I would prefer. The "varies by current CPU state"
> approach seems to me to be not the way we do things right now,
> and to be awkward for the VMM side, so it ought to have a really
> strong justification for why we need it.

> Generally the VMM doesn't care about the actual current state of the
> CPU, it just wants all the data (e.g. to send for migration). We don't
> make the current SVE accessors change based on what the current SVE
> vq length is or whether the guest has set the SVE enable bits -- we
> have "if the vcpu supports SVE at all, data is always accessed via
> the SVE accessors, and it's always the max_vq length, regardless of
> how the vcpu has set its current vq length".

OK, that's clear - that was my expectation for what userspace would want
too FWIW.

> What's the benefit of making the way KVM exposes the data
> bounce around based on the current CPU state? Does that
> make things easier for the kernel internally?

Yes, it makes life easier for the kernel internally.  If we expose the
registers to userspace with a potentially non-native format then we need
to keep track of the format things are currently stored in and rewrite
the data between the format we're exposing and the format we're going to
load/save to/from the hardware when those differ.  It's not an issue in
the normal fast path for running guests, it's only a concern when
userspace actually interacts with the affected registers.

This won't have come up in the SVE case since what's exposed is the
hypervisor view of the registers which doesn't change based on what the
guest does so you just need a bit of configuration of ZCR_ELx.LEN, with
SME the current value of PSTATE.SM changes the view of the registers for
all ELs.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)