[PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values

[Mark Rutland]

On Tue, May 26, 2026 at 11:19:38AM +0100, Mark Brown wrote:
> On Mon, May 25, 2026 at 07:36:50PM +0100, Mark Rutland wrote:
> > On Fri, May 22, 2026 at 07:00:04PM +0100, Mark Brown wrote:
> 
> > > Since b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps") when guests
> > > write to ZCR_EL2 we have clamped the value of ZCR_EL2.LEN to be at most
> > > that configuring the maximum guest VL. This is not the behaviour the
> 
> ...
> 
> > Have we sought feedback from architects? While I said "*or* the
> > architcture requires a clarification", I think it should be clarified
> > more explicitly either way given that the pattern is unusual.

The part I asked for clarification on was:

  AFAICT, none of the values for the SMCR_ELx.LEN and ZCR_ELx.LEN fields
  are reserved or unallocated. Thus all the bits of those fields should
  be stateful, and a read should observe the last value written,
  regardless of the effective value of the field.

  [...]

  Either what we're doing is wrong, or the architcture requires a
  clarification to say that values corresponding to unimplmented vector
  lengths are reserved.

> > Given this is particularly subtle, please keep me in the loop when
> > speaking with architects about this.
> 
> TBH it didn't strike me as subtle, I don't see anything in the
> architecture which would lead me to expect the current behaviour. 

The point I was trying to get across is that I don't think this is
specified clearly enough, and I think we need to get this clarified.

There's a general principle regarding reserved values. See K1.2.19
("Reserved values in System and memory-mapped registers and translation
table entries"), and specifically note "reserved values of fields".

There's no explicit statement either way regarding the values for
ZCR_ELx.LEN and SMCR_ELx.LEN. The statement regarding the selection of
the effective vector length implies *some* constraints, but
(explicitly!) doesn't specify the behaviour for direct reads.

It's possible for a reader to come to one of the following conclusions:

(a) Any value written to the LEN field must be preserved exactly. In all
    cases a read must observe the last value written.

(b) Some values written to the LEN field are reserved, and don't need to
    be preserved exactly.

    For example, since the only architecturally-defined VLs are
    powers-of-two, the only "legitimate" values are: 0b0000, 0b0001,
    0b0011, 0b0111, 0b1111. Hence any written value could be collapsed
    to that set.

(c) Some values written to the LEN field are reserved, and can be
    replaced with *any* value.

    See the statement at the end of K1.2.19 regarding subsequent reads
    returning an UNKNOWN value.

While one simple reading is that all values must be preserved exactly, I
don't think this watertight, and I think while some people will take
reading (a), others will take (b) or (c). I should have spelled that out
more clearly in my initial mail, sorry.

> The psudocode all just has direct assignments for the write

The pseudocode doesn't capture the detail I've described above.

> and there's language in the ARM (eg, in the ZCR_EL2 description)
> saying "for all purposes other than returning the result of a direct
> read of ZCR_EL2" which seems specifically intended to cover there
> being a divergence between the written and effective values, though I
> guess it doesn't explicitly mention writes in the text.  

That permits a divergence, but does not define the boundary conditions
for what a direct read can observe.

Mark.