* [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
@ 2026-05-22 18:00 Mark Brown
2026-05-23 8:47 ` Marc Zyngier
2026-05-25 18:36 ` Mark Rutland
0 siblings, 2 replies; 8+ messages in thread
From: Mark Brown @ 2026-05-22 18:00 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Catalin Marinas, Will Deacon
Cc: Mark Rutland, linux-arm-kernel, kvmarm, linux-kernel, Mark Brown
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
architecture documents for ZCR_EL2.LEN, the expectation is that all bits
will be read as written. Further, writing values larger than the largest
available vector length is part of the documented procedure for enumerating
the supported vector lengths so we expect to see this happen in practice.
The reasoning for the current behaviour is not specifically articulated, my
best guess is that it is intended to ensure that the guest can not see an
effective VL greater than the maximum that has been configured. This can
instead be achieved by configuring ZCR_EL2 when loading guest state:
- When running at EL0 or EL1 configure ZCR_EL2.LEN to the minimum of the
guest ZCR_EL2.LEN and vcpu_sve_max_vq(vcpu)-1.
- When running at EL2 configure the maximum VL for the guest in
ZCR_EL2.LEN like we do for non-nested guests and load the guest
ZCR_EL2 into ZCR_EL1.
This will ensure that the guest sees both the ZCR_EL2.LEN value which it
wrote and the effective VL that resulting from the values it has configured
in ZCR_ELx.LEN.
Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
written are sanitised based on this.
Fixes: b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps")
Signed-off-by: Mark Brown <broonie@kernel•org>
---
arch/arm64/kvm/hyp/include/hyp/switch.h | 8 ++++----
arch/arm64/kvm/sys_regs.c | 6 +-----
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index bf0eb5e43427..fd277cb70967 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -501,11 +501,11 @@ static inline void fpsimd_lazy_switch_to_guest(struct kvm_vcpu *vcpu)
return;
if (vcpu_has_sve(vcpu)) {
+ zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
+
/* A guest hypervisor may restrict the effective max VL. */
- if (is_nested_ctxt(vcpu))
- zcr_el2 = __vcpu_sys_reg(vcpu, ZCR_EL2);
- else
- zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
+ if (is_nested_ctxt(vcpu) && !is_hyp_ctxt(vcpu))
+ zcr_el2 = min(zcr_el2, __vcpu_sys_reg(vcpu, ZCR_EL2));
write_sysreg_el2(zcr_el2, SYS_ZCR);
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 148fc3400ea8..c4d3bbae2d14 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2862,8 +2862,6 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
- unsigned int vq;
-
if (guest_hyp_sve_traps_enabled(vcpu)) {
kvm_inject_nested_sve_trap(vcpu);
return false;
@@ -2874,9 +2872,7 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
return true;
}
- vq = SYS_FIELD_GET(ZCR_ELx, LEN, p->regval) + 1;
- vq = min(vq, vcpu_sve_max_vq(vcpu));
- __vcpu_assign_sys_reg(vcpu, ZCR_EL2, vq - 1);
+ __vcpu_assign_sys_reg(vcpu, ZCR_EL2, p->regval & ZCR_ELx_LEN);
return true;
}
---
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
change-id: 20260519-kvm-arm64-fix-zcr-len-nv-9e9e7bae012a
Best regards,
--
Mark Brown <broonie@kernel•org>
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
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-25 18:36 ` Mark Rutland
1 sibling, 1 reply; 8+ messages in thread
From: Marc Zyngier @ 2026-05-23 8:47 UTC (permalink / raw)
To: Mark Brown
Cc: Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Catalin Marinas, Will Deacon, Mark Rutland, linux-arm-kernel,
kvmarm, linux-kernel
On Fri, 22 May 2026 19:00:04 +0100,
Mark Brown <broonie@kernel•org> 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.
That's not strictly true. This is only clamped when accessed as
ZCR_EL2. A VHE guest will happily use the ZCR_EL1 accessor for the
same register, and not see the truncation. This has ripple effects
down the line, where the full value will be used at load time.
> This is not the behaviour the
> architecture documents for ZCR_EL2.LEN, the expectation is that all bits
> will be read as written. Further, writing values larger than the largest
> available vector length is part of the documented procedure for enumerating
> the supported vector lengths so we expect to see this happen in practice.
>
> The reasoning for the current behaviour is not specifically articulated, my
> best guess is that it is intended to ensure that the guest can not see an
> effective VL greater than the maximum that has been configured. This can
> instead be achieved by configuring ZCR_EL2 when loading guest state:
>
> - When running at EL0 or EL1 configure ZCR_EL2.LEN to the minimum of the
> guest ZCR_EL2.LEN and vcpu_sve_max_vq(vcpu)-1.
This is not EL0 or EL1. This is when in a nested context (i.e. running
a L2 guest), as EL0 exists for L1 as well.
> - When running at EL2 configure the maximum VL for the guest in
> ZCR_EL2.LEN like we do for non-nested guests and load the guest
> ZCR_EL2 into ZCR_EL1.
>
> This will ensure that the guest sees both the ZCR_EL2.LEN value which it
> wrote and the effective VL that resulting from the values it has configured
> in ZCR_ELx.LEN.
>
> Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
> written are sanitised based on this.
Only for the direct writes to ZCR_EL2, as they are trapping. I don't
see any sanitisation for writes using the ZCR_EL1 accessor, which is
the common case. This needs fixing at the same time.
>
> Fixes: b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps")
> Signed-off-by: Mark Brown <broonie@kernel•org>
Given the nature of the bug, this needs a Cc: stable.
> ---
> arch/arm64/kvm/hyp/include/hyp/switch.h | 8 ++++----
> arch/arm64/kvm/sys_regs.c | 6 +-----
> 2 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index bf0eb5e43427..fd277cb70967 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -501,11 +501,11 @@ static inline void fpsimd_lazy_switch_to_guest(struct kvm_vcpu *vcpu)
> return;
>
> if (vcpu_has_sve(vcpu)) {
> + zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
> +
> /* A guest hypervisor may restrict the effective max VL. */
> - if (is_nested_ctxt(vcpu))
> - zcr_el2 = __vcpu_sys_reg(vcpu, ZCR_EL2);
> - else
> - zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
> + if (is_nested_ctxt(vcpu) && !is_hyp_ctxt(vcpu))
> + zcr_el2 = min(zcr_el2, __vcpu_sys_reg(vcpu, ZCR_EL2));
Why the change in the condition guarding this? Given the definition of
is_nested_ctxt(), this seems unnecessary.
>
> write_sysreg_el2(zcr_el2, SYS_ZCR);
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 148fc3400ea8..c4d3bbae2d14 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2862,8 +2862,6 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
> struct sys_reg_params *p,
> const struct sys_reg_desc *r)
> {
> - unsigned int vq;
> -
> if (guest_hyp_sve_traps_enabled(vcpu)) {
> kvm_inject_nested_sve_trap(vcpu);
> return false;
> @@ -2874,9 +2872,7 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
> return true;
> }
>
> - vq = SYS_FIELD_GET(ZCR_ELx, LEN, p->regval) + 1;
> - vq = min(vq, vcpu_sve_max_vq(vcpu));
> - __vcpu_assign_sys_reg(vcpu, ZCR_EL2, vq - 1);
> + __vcpu_assign_sys_reg(vcpu, ZCR_EL2, p->regval & ZCR_ELx_LEN);
Once you have added the full ZCR_EL2 sanitisation, this masking can go.
> return true;
> }
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
2026-05-23 8:47 ` Marc Zyngier
@ 2026-05-23 14:38 ` Mark Brown
2026-05-23 15:24 ` Marc Zyngier
0 siblings, 1 reply; 8+ messages in thread
From: Mark Brown @ 2026-05-23 14:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Catalin Marinas, Will Deacon, Mark Rutland, linux-arm-kernel,
kvmarm, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
On Sat, May 23, 2026 at 09:47:38AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@kernel•org> wrote:
> > The reasoning for the current behaviour is not specifically articulated, my
> > best guess is that it is intended to ensure that the guest can not see an
> > effective VL greater than the maximum that has been configured. This can
> > instead be achieved by configuring ZCR_EL2 when loading guest state:
> > - When running at EL0 or EL1 configure ZCR_EL2.LEN to the minimum of the
> > guest ZCR_EL2.LEN and vcpu_sve_max_vq(vcpu)-1.
> This is not EL0 or EL1. This is when in a nested context (i.e. running
> a L2 guest), as EL0 exists for L1 as well.
Sorry, this was intended to be specifically for a L2 guest but didn't
actually say that. I originally had more verbosity in the commit log
that I cleaned up too much, making things unclear. I will clarify.
> > Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
> > written are sanitised based on this.
> Only for the direct writes to ZCR_EL2, as they are trapping. I don't
> see any sanitisation for writes using the ZCR_EL1 accessor, which is
> the common case. This needs fixing at the same time.
OK, I'll convert ZCR_EL2 to a sanitised register. As I mentioned I was
a bit confused about why the existing code is the way it is and so
followed it in only managing the direct writes. I figured it was
considered OK to rely on the hardware for the RES0 and WI behaviour for
untrapped access.
> > - if (is_nested_ctxt(vcpu)) - zcr_el2
> > = __vcpu_sys_reg(vcpu, ZCR_EL2); - else -
> > zcr_el2 = vcpu_sve_max_vq(vcpu) - 1; + if
> > (is_nested_ctxt(vcpu) && !is_hyp_ctxt(vcpu)) +
> > zcr_el2 = min(zcr_el2, __vcpu_sys_reg(vcpu, ZCR_EL2));
> Why the change in the condition guarding this? Given the definition of
> is_nested_ctxt(), this seems unnecessary.
You're right, this change is not needed. I had misremembered what
is_nested_ctxt() was checking.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
2026-05-23 14:38 ` Mark Brown
@ 2026-05-23 15:24 ` Marc Zyngier
0 siblings, 0 replies; 8+ messages in thread
From: Marc Zyngier @ 2026-05-23 15:24 UTC (permalink / raw)
To: Mark Brown
Cc: Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Catalin Marinas, Will Deacon, Mark Rutland, linux-arm-kernel,
kvmarm, linux-kernel
On Sat, 23 May 2026 15:38:28 +0100,
Mark Brown <broonie@kernel•org> wrote:
>
> On Sat, May 23, 2026 at 09:47:38AM +0100, Marc Zyngier wrote:
> > Mark Brown <broonie@kernel•org> wrote:
>
> > > Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
> > > written are sanitised based on this.
>
> > Only for the direct writes to ZCR_EL2, as they are trapping. I don't
> > see any sanitisation for writes using the ZCR_EL1 accessor, which is
> > the common case. This needs fixing at the same time.
>
> OK, I'll convert ZCR_EL2 to a sanitised register. As I mentioned I was
> a bit confused about why the existing code is the way it is and so
> followed it in only managing the direct writes. I figured it was
> considered OK to rely on the hardware for the RES0 and WI behaviour for
> untrapped access.
In general, that's OK. But given that you need sanitisation in the
trapping case, it is way better to have a uniform behaviour and keep
sanitisation at the accessor level. It is also more sustainable in the
long run, should ZCR_ELx get new significant bits.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
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-25 18:36 ` Mark Rutland
2026-05-26 10:19 ` Mark Brown
1 sibling, 1 reply; 8+ messages in thread
From: Mark Rutland @ 2026-05-25 18:36 UTC (permalink / raw)
To: Mark Brown
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
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
> architecture documents for ZCR_EL2.LEN, the expectation is that all bits
> will be read as written. Further, writing values larger than the largest
> available vector length is part of the documented procedure for enumerating
> the supported vector lengths so we expect to see this happen in practice.
>
> The reasoning for the current behaviour is not specifically articulated, my
> best guess is that it is intended to ensure that the guest can not see an
> effective VL greater than the maximum that has been configured. This can
> instead be achieved by configuring ZCR_EL2 when loading guest state:
>
> - When running at EL0 or EL1 configure ZCR_EL2.LEN to the minimum of the
> guest ZCR_EL2.LEN and vcpu_sve_max_vq(vcpu)-1.
> - When running at EL2 configure the maximum VL for the guest in
> ZCR_EL2.LEN like we do for non-nested guests and load the guest
> ZCR_EL2 into ZCR_EL1.
>
> This will ensure that the guest sees both the ZCR_EL2.LEN value which it
> wrote and the effective VL that resulting from the values it has configured
> in ZCR_ELx.LEN.
>
> Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
> written are sanitised based on this.
>
> Fixes: b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps")
> Signed-off-by: Mark Brown <broonie@kernel•org>
For context, I mentioned this potential problem to Mark, and described
this possible solution at:
https://lore.kernel.org/linux-arm-kernel/af4bWxiOogfPz_dp@J2N7QTR9R3/
I said:
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.
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.
Given this is particularly subtle, please keep me in the loop when
speaking with architects about this.
Mark.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
2026-05-25 18:36 ` Mark Rutland
@ 2026-05-26 10:19 ` Mark Brown
2026-05-26 12:03 ` Mark Rutland
0 siblings, 1 reply; 8+ messages in thread
From: Mark Brown @ 2026-05-26 10:19 UTC (permalink / raw)
To: Mark Rutland
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]
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.
> 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
psudocode all just has direct assignments for the write 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.
When I saw the code it looked like something KVM was doing for some
KVM reason that was obscure to me, the lack of clarity seemed like it
was on the KVM side.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
2026-05-26 10:19 ` Mark Brown
@ 2026-05-26 12:03 ` Mark Rutland
2026-05-26 13:03 ` Mark Brown
0 siblings, 1 reply; 8+ messages in thread
From: Mark Rutland @ 2026-05-26 12:03 UTC (permalink / raw)
To: Mark Brown
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
2026-05-26 12:03 ` Mark Rutland
@ 2026-05-26 13:03 ` Mark Brown
0 siblings, 0 replies; 8+ messages in thread
From: Mark Brown @ 2026-05-26 13:03 UTC (permalink / raw)
To: Mark Rutland
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
On Tue, May 26, 2026 at 01:03:19PM +0100, Mark Rutland wrote:
> On Tue, May 26, 2026 at 11:19:38AM +0100, Mark Brown wrote:
> 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.
...
> 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.
I see. Given the general tendency to brevity it didn't occur to me that
options b or c might be a thing.
FWIW the restriction to powers of 2 was a revision in the architecture,
originally all values were allowed, though it's there now so the history
doesn't make a huge difference.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2026-05-26 13:04 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2026-05-26 13:03 ` Mark Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox