Message-ID: <30488f61-3233-4cf3-995d-717436de60f6@sirena.org.uk>
Date: Tue, 13 Jan 2026 16:10:53 +0000
From: Mark Brown <broonie@...nel.org>
To: Fuad Tabba <tabba@...gle.com>
Cc: Marc Zyngier <maz@...nel.org>, 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>,
	Oliver Upton <oupton@...nel.org>, Dave Martin <Dave.Martin@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ben Horgan <ben.horgan@....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,
	Peter Maydell <peter.maydell@...aro.org>,
	Eric Auger <eric.auger@...hat.com>
Subject: Re: [PATCH v9 00/30] KVM: arm64: Implement support for SME

On Tue, Jan 13, 2026 at 02:58:37PM +0000, Fuad Tabba wrote:
> On Tue, 23 Dec 2025 at 01:21, Mark Brown <broonie@...nel.org> wrote:

> > Changing the value of SVCR.SM will result in the contents of
> > the Z, P and FFR registers being reset to 0.  When restoring the
> > values of these registers for a VM with SME support it is
> > important that SVCR.SM be configured first.

> However, the order returned by kvm_arm_copy_reg_indices() is core,
> sve, fw, then system. So this means that the VMM will need to hardcode
> this order, rather than rely on KVM_GET_REG_LIST. It _is_ documented,
> but it is tricky and it's easy to miss.

> Looking at copy_sve_reg_indices(), there's a special case for
> KVM_REG_ARM64_SVE_VLS, which forces it to appear before the other SVE
> registers. So I wonder if we need to do something at the level of
> kvm_arm_copy_reg_indices(), or do some sort of post-processing to the
> list, to avoid this problem.

That makes sense.  The whole ordering dependency thing is obviously a
landmine so if we can do something to make it more likely that things
will go right then that seems helpful.

> >  - The userspace ABI, in particular:
> >   - The vector length used for the SVE registers, access to the SVE
> >     registers and access to ZA and (if available) ZT0 depending on
> >     the current state of PSTATE.{SM,ZA}.

> One issue I see here, from a VMM's perspective, is that the amount of
> data transferred via KVM_GET_ONE_REG/KVM_SET_ONE_REG depends on the
> guest's current architectural mode. So now the VMM needs to first
> figure out what that is, before being able to SET/GET when
> saving/restoring a VM state.

> Before this series, SVE just assumed a maximum amount of data and
> zero-pad the rest. SME state is bigger, but in practice, do we expect
> many cases where the VL sizes between modes would be drastically
> different that it would make a difference in terms of storage?

I would expect it to be very common for the forseeable future that the
SME vector length will be several times that for SVE with no overlap.

> Other than that, I think the asymmetry of VLs might be a painpoint for
> users. The problem is that there is no guarantee that the set of
> vector lengths supported for SME match or the set supported for SVE.
> But I wonder if there's something we can do to help. Maybe a discovery
> IOCTL that returns the entire matrix of supported configurations (SVE
> VLs, SME VLs, and their intersection) to simplify VMM decision-making?

I'm thinking such discovery might be better assisted with a userspace
library, as well as KVM VMMs it's also an issue for things like
debuggers and trying to design something nice that's also an ioctl()
feels a lot harder to get right.

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

Powered by blists - more mailing lists