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

On Wed, Nov 26, 2025 at 05:23:47PM +0000, Dave Martin wrote:

On Mon, Nov 24, 2025 at 08:12:56PM +0000, Mark Brown wrote:

quoted

On Mon, Nov 24, 2025 at 03:48:06PM +0000, Peter Maydell wrote:

quoted

quoted

quoted

 .. [1] These encodings are not accepted for SVE-enabled vcpus.  See
-       :ref:`KVM_ARM_VCPU_INIT`.
+       :ref:`KVM_ARM_VCPU_INIT`.  They are also not accepted when SME is
+       enabled without SVE and the vcpu is in streaming mode.

quoted

quoted

Does this mean that on an SME-no-SVE VM the VMM needs to know
if the vcpu is currently in streaming mode or not to determine
whether to read the FP registers as fp_regs or sve regs? That
seems unpleasant -- I was expecting this to be strictly a
matter of how the VM was configured (as it is with SVE).

quoted

Yes, it does.

Is the above condition right re streaming mode?  The original reason
for this restriction was that the SVE Z-regs and FPSIMD V-regs are
aliases when SVE is present.  To avoid having to worry about how to
order register accesses and/or paste parts of them together, we went
down the road of banishing encodings that alias a subset of the
register state accessed by some other encoding.

I queried the issue with requiring that writes to the registers be done
in a specific order - we apparently have some other examples of this
already (I would need to go and check which specifically) so that was
seen as OK.

In line with this principle, with SME Vn and Zn are aliases when
*not* in streaming mode, so allowing access through the Vn view feels
problematic too?  (And when in streaming mode, the Vn regs don't exist
at all.)

The ABI proposed here is that the V registers will only be available
with a VM that lacks SVE, you'll never have them both simultaneously but
rather which is available at any given moment will vary on a SME without
SVE VM.  This obviously has complications, but aliasing is not one of
them.

Another option would be to represent the V registers as 128 bit Z
registers, giving you something similar to how they'd appear on a VM
with both SVE and SME for a SME only VM.

Whether the proposed ABI is considered awkward for VMMs or not is a
separate matter...)

Indeed.

quoted

quoted

quoted

+       max_vq.  This is the maximum vector length currently available to
+       the guest on this vcpu, and determines which register slices are
+       visible through this ioctl interface.

quoted

quoted

+       If SME is supported then the max_vq used for the Z and P registers
+       while SVCR.SM is 1 this vector length will be the maximum SME
+       vector length available for the guest, otherwise it will be the
+       maximum SVE vector length available.

The max_vq name here is not ABI; it's just linking concepts together in
the documentation text.

So, can we give explicitly different names to these two max_vq values?

We could call them sve_max_vq and sme_max_vq?

Splitting the affected register descriptions into "SVCR.SM == 0" and
"SVCR.SM == 1" cases also be helpful to make this special-casing clear.

Possibly I'm looking at the wrong thing here but the overall text for
describing the vector registers is relatively long so I worry that it'd
be harder for readers to play spot the difference if there was
duplication.  I figured explicitly calling out the differences would be
clearer and less error prone in terms of any future updates.

quoted

This is attempting to say that the VL for the Z and P registers (and
FFR) will vary depending on if the vCPU is in streaming mode or not if
the maximum VL for SVE and SME differs, similarly to how the Z, P and
FFR registers disappear when we are not in streaming mode in a SME only
system.

May flipping SVCR.SM through KVM_SET_ONE_REG have the architectural
effect of zeroing the vector regs?  That feels like something that
should be stated explicitly.

Yes, it should zero them - I'll find some place/way to add that.

I'd agree that this mutating interface feels odd, and does not follow
the original spirit of the design here.

But the SME architecture doesn't fit well with the spirit of the
original KVM ABI here either, so I guess there won't be a perfect
solution.

Something's going to be awkward somewhere.

It seems that when SME is enabled in the vCPU features and the VMM is
planning to dump or set affected registers, there is a requirement to
dump / set SVCR.SM first, and then go down one of two code paths.  Can
this be called out explicitly?  This is a departure from the the
previous interaction model, so it probably deserves its own section,
which can then be cross-referenced from individual reg
descriptions.

SVCR.SM exhibits this modality w.r.t a specific set of affected
register encodings; it would be good to have that captured clearly in
one place.

As I said above my understanding is that this is not actually a
departure from the current stituation, this not being noticed probably
highlights why it'd be good to improve the documentation here!  I think
grouping all behaviours like this together would be good from a
usability point of view.  I don't know how much of that that fits
directly in the ABI document or in a separate "here's some gotchas" type
document, things are already getting a bit difficult to manage.
Possibly both.