[PATCH v9 00/30] KVM: arm64: Implement support for SME

[Mark Brown]

On Tue, Jan 13, 2026 at 02:58:37PM +0000, Fuad Tabba wrote:
> On Tue, 23 Dec 2025 at 01:21, Mark Brown <broonie at kernel.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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260113/068091a9/attachment.sig>