On Tue, Jan 13, 2026 at 02:58:37PM +0000, Fuad Tabba wrote:

On Tue, 23 Dec 2025 at 01:21, Mark Brown [off-list ref] wrote:

quoted

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.

quoted

 - 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.