On Tue, Jan 13, 2026 at 02:58:37PM +0000, Fuad Tabba wrote:
On Tue, 23 Dec 2025 at 01:21, Mark Brown broonie@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.