From: Mark Rutland <mark.rutland@arm•com>
To: Mark Brown <broonie@kernel•org>
Cc: Marc Zyngier <maz@kernel•org>, Oliver Upton <oupton@kernel•org>,
Joey Gouly <joey.gouly@arm•com>,
Steffen Eiden <seiden@linux•ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm•com>,
Catalin Marinas <catalin.marinas@arm•com>,
Will Deacon <will@kernel•org>,
linux-arm-kernel@lists•infradead.org, kvmarm@lists•linux.dev,
linux-kernel@vger•kernel.org
Subject: Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
Date: Tue, 26 May 2026 13:03:19 +0100 [thread overview]
Message-ID: <ahWMByoIme6_oECX@J2N7QTR9R3> (raw)
In-Reply-To: <b4fdceb6-5fa7-4829-a60e-6f80f47f032a@sirena.org.uk>
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.
next prev parent reply other threads:[~2026-05-26 12:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 18:00 [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values Mark Brown
2026-05-23 8:47 ` Marc Zyngier
2026-05-23 14:38 ` Mark Brown
2026-05-23 15:24 ` Marc Zyngier
2026-05-25 18:36 ` Mark Rutland
2026-05-26 10:19 ` Mark Brown
2026-05-26 12:03 ` Mark Rutland [this message]
2026-05-26 13:03 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ahWMByoIme6_oECX@J2N7QTR9R3 \
--to=mark.rutland@arm$(echo .)com \
--cc=broonie@kernel$(echo .)org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=joey.gouly@arm$(echo .)com \
--cc=kvmarm@lists$(echo .)linux.dev \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=maz@kernel$(echo .)org \
--cc=oupton@kernel$(echo .)org \
--cc=seiden@linux$(echo .)ibm.com \
--cc=suzuki.poulose@arm$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox