* Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection
2025-10-09 12:12 [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection Marc Zyngier
@ 2025-10-09 13:00 ` Mark Rutland
2025-10-09 14:10 ` Marc Zyngier
2025-10-09 21:30 ` Oliver Upton
` (2 subsequent siblings)
3 siblings, 1 reply; 10+ messages in thread
From: Mark Rutland @ 2025-10-09 13:00 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, kvmarm, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Will Deacon, Catalin Marinas, Jan Kotas
On Thu, Oct 09, 2025 at 01:12:39PM +0100, Marc Zyngier wrote:
> We currently have two ways to identify CPUs that only implement FEAT_VHE
> and not FEAT_E2H0:
>
> - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
> - or the HCR_EL2.E2H bit is RAO/WI
>
> However, there is a third category of "cpus" that fall between these
> two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
> an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
> is zero.
>
> A consequence of this is that on systems such as Neoverse V2, a NV
> guest cannot reliably detect that it is in a VHE-only configuration
> (E2H is writable, and ID_AA64MMFR0_EL1 is 0), despite the hypervisor's
> best effort to repaint the id register.
>
> Replace the RAO/WI test by a sequence that makes use of the VHE
> register remnapping between EL1 and EL2 to detect this situation,
> and work out whether we get the VHE behaviour even after having
> set HCR_EL2.E2H to 0.
>
> This solves the NV problem, and provides a more reliable acid test
> for CPUs that do not completely follow the letter of the architecture
> while providing a RES1 behaviour for HCR_EL2.E2H.
>
> Suggested-by: Marc Rutland <mark.rutland@arm.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/r/15A85F2B-1A0C-4FA7-9FE4-EEC2203CC09E@global.cadence.com
> ---
> arch/arm64/include/asm/el2_setup.h | 30 ++++++++++++++++++++++++------
> 1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
> index 46033027510cc..b7640e2c20503 100644
> --- a/arch/arm64/include/asm/el2_setup.h
> +++ b/arch/arm64/include/asm/el2_setup.h
> @@ -24,22 +24,40 @@
> * ID_AA64MMFR4_EL1.E2H0 < 0. On such CPUs HCR_EL2.E2H is RES1, but it
> * can reset into an UNKNOWN state and might not read as 1 until it has
> * been initialized explicitly.
> - *
> - * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but
> - * don't advertise it (they predate this relaxation).
> - *
> * Initalize HCR_EL2.E2H so that later code can rely upon HCR_EL2.E2H
> * indicating whether the CPU is running in E2H mode.
> */
> mrs_s x1, SYS_ID_AA64MMFR4_EL1
> sbfx x1, x1, #ID_AA64MMFR4_EL1_E2H0_SHIFT, #ID_AA64MMFR4_EL1_E2H0_WIDTH
> cmp x1, #0
> - b.ge .LnVHE_\@
> + b.lt .LnE2H0_\@
>
> + /*
> + * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but don't
> + * advertise it (they predate this relaxation). Check for an
> + * essential VHE property (system register remapping) to decide
> + * whether we're effectively VHE-only or not.
> + *
> + * This is also useful for for NV guests on CPUs that can't trap
> + * ID_AA64MMFR4_EL1 as they don't have FEAT_FGT.
> + */
Would you be happy to elaborate this comment to:
/*
* Unfortunately, HCR_EL2.E2H can be RES1 even if not advertised
* as such via ID_AA64MMFR4_EL1.E2H0:
*
* - Fruity CPUs predate the !FEAT_E2H0 relaxation, and seem to
* have HCR_EL2.E2H implemented as RAO/WI.
*
* - On CPUs that lack FEAT_FGT, a hypervisor can't trap guest
* reads of ID_AA64MMFR4_EL1 to advertise !FEAT_E2H0. NV
* guests on these hosts can write to HCR_EL2.E2H without
* trapping to the hypervisor, but these writes have no
* functional effect.
*
* Handle both cases by checking for an essential VHE property
* (system register remapping) to decide whether we're
* effectively VHE-only or not.
*/
Other than that, this all looks good to me:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> + msr_hcr_el2 x0 // Setup HCR_EL2 as nVHE
> + isb
> + mov x1, #1 // Write something to FAR_EL1
> + msr far_el1, x1
> + isb
> + mov x1, #2 // Try to overwrite it via FAR_EL2
> + msr far_el2, x1
> + isb
> + mrs x1, far_el1 // If we see the latest write in FAR_EL1,
> + cmp x1, #2 // we can safely assume we are VHE only.
> + b.ne .LnVHE_\@ // Otherwise, we know that nVHE works.
> +
> +.LnE2H0_\@:
> orr x0, x0, #HCR_E2H
> -.LnVHE_\@:
> msr_hcr_el2 x0
> isb
> +.LnVHE_\@:
> .endm
>
> .macro __init_el2_sctlr
> --
> 2.47.3
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection
2025-10-09 13:00 ` Mark Rutland
@ 2025-10-09 14:10 ` Marc Zyngier
2025-10-09 15:15 ` Jan Kotas
0 siblings, 1 reply; 10+ messages in thread
From: Marc Zyngier @ 2025-10-09 14:10 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, kvmarm, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Will Deacon, Catalin Marinas, Jan Kotas
On Thu, 09 Oct 2025 14:00:22 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Thu, Oct 09, 2025 at 01:12:39PM +0100, Marc Zyngier wrote:
> > We currently have two ways to identify CPUs that only implement FEAT_VHE
> > and not FEAT_E2H0:
> >
> > - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
> > - or the HCR_EL2.E2H bit is RAO/WI
> >
> > However, there is a third category of "cpus" that fall between these
> > two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
> > an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
> > is zero.
> >
> > A consequence of this is that on systems such as Neoverse V2, a NV
> > guest cannot reliably detect that it is in a VHE-only configuration
> > (E2H is writable, and ID_AA64MMFR0_EL1 is 0), despite the hypervisor's
> > best effort to repaint the id register.
> >
> > Replace the RAO/WI test by a sequence that makes use of the VHE
> > register remnapping between EL1 and EL2 to detect this situation,
> > and work out whether we get the VHE behaviour even after having
> > set HCR_EL2.E2H to 0.
> >
> > This solves the NV problem, and provides a more reliable acid test
> > for CPUs that do not completely follow the letter of the architecture
> > while providing a RES1 behaviour for HCR_EL2.E2H.
> >
> > Suggested-by: Marc Rutland <mark.rutland@arm.com>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Link: https://lore.kernel.org/r/15A85F2B-1A0C-4FA7-9FE4-EEC2203CC09E@global.cadence.com
> > ---
> > arch/arm64/include/asm/el2_setup.h | 30 ++++++++++++++++++++++++------
> > 1 file changed, 24 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
> > index 46033027510cc..b7640e2c20503 100644
> > --- a/arch/arm64/include/asm/el2_setup.h
> > +++ b/arch/arm64/include/asm/el2_setup.h
> > @@ -24,22 +24,40 @@
> > * ID_AA64MMFR4_EL1.E2H0 < 0. On such CPUs HCR_EL2.E2H is RES1, but it
> > * can reset into an UNKNOWN state and might not read as 1 until it has
> > * been initialized explicitly.
> > - *
> > - * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but
> > - * don't advertise it (they predate this relaxation).
> > - *
> > * Initalize HCR_EL2.E2H so that later code can rely upon HCR_EL2.E2H
> > * indicating whether the CPU is running in E2H mode.
> > */
> > mrs_s x1, SYS_ID_AA64MMFR4_EL1
> > sbfx x1, x1, #ID_AA64MMFR4_EL1_E2H0_SHIFT, #ID_AA64MMFR4_EL1_E2H0_WIDTH
> > cmp x1, #0
> > - b.ge .LnVHE_\@
> > + b.lt .LnE2H0_\@
> >
>
> > + /*
> > + * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but don't
> > + * advertise it (they predate this relaxation). Check for an
> > + * essential VHE property (system register remapping) to decide
> > + * whether we're effectively VHE-only or not.
> > + *
> > + * This is also useful for for NV guests on CPUs that can't trap
> > + * ID_AA64MMFR4_EL1 as they don't have FEAT_FGT.
> > + */
>
> Would you be happy to elaborate this comment to:
>
> /*
> * Unfortunately, HCR_EL2.E2H can be RES1 even if not advertised
> * as such via ID_AA64MMFR4_EL1.E2H0:
> *
> * - Fruity CPUs predate the !FEAT_E2H0 relaxation, and seem to
> * have HCR_EL2.E2H implemented as RAO/WI.
> *
> * - On CPUs that lack FEAT_FGT, a hypervisor can't trap guest
> * reads of ID_AA64MMFR4_EL1 to advertise !FEAT_E2H0. NV
> * guests on these hosts can write to HCR_EL2.E2H without
> * trapping to the hypervisor, but these writes have no
> * functional effect.
> *
> * Handle both cases by checking for an essential VHE property
> * (system register remapping) to decide whether we're
> * effectively VHE-only or not.
> */
Yup. Applied.
>
> Other than that, this all looks good to me:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks!
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection
2025-10-09 14:10 ` Marc Zyngier
@ 2025-10-09 15:15 ` Jan Kotas
0 siblings, 0 replies; 10+ messages in thread
From: Jan Kotas @ 2025-10-09 15:15 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Will Deacon, Catalin Marinas, Jan Kotas
> On 9 Oct 2025, at 16:10, Marc Zyngier <maz@kernel.org> wrote:
>
> EXTERNAL MAIL
>
>
> On Thu, 09 Oct 2025 14:00:22 +0100,
> Mark Rutland <mark.rutland@arm.com> wrote:
>>
>> On Thu, Oct 09, 2025 at 01:12:39PM +0100, Marc Zyngier wrote:
>>> We currently have two ways to identify CPUs that only implement FEAT_VHE
>>> and not FEAT_E2H0:
>>>
>>> - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
>>> - or the HCR_EL2.E2H bit is RAO/WI
>>>
>>> However, there is a third category of "cpus" that fall between these
>>> two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
>>> an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
>>> is zero.
>>>
>>> A consequence of this is that on systems such as Neoverse V2, a NV
>>> guest cannot reliably detect that it is in a VHE-only configuration
>>> (E2H is writable, and ID_AA64MMFR0_EL1 is 0), despite the hypervisor's
>>> best effort to repaint the id register.
>>>
>>> Replace the RAO/WI test by a sequence that makes use of the VHE
>>> register remnapping between EL1 and EL2 to detect this situation,
>>> and work out whether we get the VHE behaviour even after having
>>> set HCR_EL2.E2H to 0.
>>>
>>> This solves the NV problem, and provides a more reliable acid test
>>> for CPUs that do not completely follow the letter of the architecture
>>> while providing a RES1 behaviour for HCR_EL2.E2H.
>>>
>>> Suggested-by: Marc Rutland <mark.rutland@arm.com>
>>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>>> Link: https://urldefense.com/v3/__https://lore.kernel.org/r/15A85F2B-1A0C-4FA7-9FE4-EEC2203CC09E@global.cadence.com__;!!EHscmS1ygiU1lA!CgHR7mq8v0OMxlFNUnMJU9oQbdQUMKM4aqCTSj6AfXwJUJssNBDP_LJCfmcZuKxkC-aq1Ce7$
>>> ---
>>> arch/arm64/include/asm/el2_setup.h | 30 ++++++++++++++++++++++++------
>>> 1 file changed, 24 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
>>> index 46033027510cc..b7640e2c20503 100644
>>> --- a/arch/arm64/include/asm/el2_setup.h
>>> +++ b/arch/arm64/include/asm/el2_setup.h
>>> @@ -24,22 +24,40 @@
>>> * ID_AA64MMFR4_EL1.E2H0 < 0. On such CPUs HCR_EL2.E2H is RES1, but it
>>> * can reset into an UNKNOWN state and might not read as 1 until it has
>>> * been initialized explicitly.
>>> - *
>>> - * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but
>>> - * don't advertise it (they predate this relaxation).
>>> - *
>>> * Initalize HCR_EL2.E2H so that later code can rely upon HCR_EL2.E2H
>>> * indicating whether the CPU is running in E2H mode.
>>> */
>>> mrs_s x1, SYS_ID_AA64MMFR4_EL1
>>> sbfx x1, x1, #ID_AA64MMFR4_EL1_E2H0_SHIFT, #ID_AA64MMFR4_EL1_E2H0_WIDTH
>>> cmp x1, #0
>>> - b.ge .LnVHE_\@
>>> + b.lt .LnE2H0_\@
>>>
>>
>>> + /*
>>> + * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but don't
>>> + * advertise it (they predate this relaxation). Check for an
>>> + * essential VHE property (system register remapping) to decide
>>> + * whether we're effectively VHE-only or not.
>>> + *
>>> + * This is also useful for for NV guests on CPUs that can't trap
>>> + * ID_AA64MMFR4_EL1 as they don't have FEAT_FGT.
>>> + */
>>
>> Would you be happy to elaborate this comment to:
>>
>> /*
>> * Unfortunately, HCR_EL2.E2H can be RES1 even if not advertised
>> * as such via ID_AA64MMFR4_EL1.E2H0:
>> *
>> * - Fruity CPUs predate the !FEAT_E2H0 relaxation, and seem to
>> * have HCR_EL2.E2H implemented as RAO/WI.
>> *
>> * - On CPUs that lack FEAT_FGT, a hypervisor can't trap guest
>> * reads of ID_AA64MMFR4_EL1 to advertise !FEAT_E2H0. NV
>> * guests on these hosts can write to HCR_EL2.E2H without
>> * trapping to the hypervisor, but these writes have no
>> * functional effect.
>> *
>> * Handle both cases by checking for an essential VHE property
>> * (system register remapping) to decide whether we're
>> * effectively VHE-only or not.
>> */
>
> Yup. Applied.
>
>>
>> Other than that, this all looks good to me:
>>
>> Acked-by: Mark Rutland <mark.rutland@arm.com>
I tested on a Neoverse-V2 machine.
Works as expected with KVM_ARM_VCPU_HAS_EL2_E2H0, and without it.
Tested-by: Jan Kotas <jank@cadence.com>
Regards,
Jan
>
> Thanks!
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection
2025-10-09 12:12 [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection Marc Zyngier
2025-10-09 13:00 ` Mark Rutland
@ 2025-10-09 21:30 ` Oliver Upton
2025-10-10 9:22 ` Marc Zyngier
2025-10-13 11:17 ` Catalin Marinas
2025-10-14 8:49 ` Marc Zyngier
3 siblings, 1 reply; 10+ messages in thread
From: Oliver Upton @ 2025-10-09 21:30 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, kvmarm, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Will Deacon, Catalin Marinas, Mark Rutland, Jan Kotas
Hey,
On Thu, Oct 09, 2025 at 01:12:39PM +0100, Marc Zyngier wrote:
> We currently have two ways to identify CPUs that only implement FEAT_VHE
> and not FEAT_E2H0:
>
> - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
> - or the HCR_EL2.E2H bit is RAO/WI
>
> However, there is a third category of "cpus" that fall between these
> two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
> an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
> is zero.
>
> A consequence of this is that on systems such as Neoverse V2, a NV
> guest cannot reliably detect that it is in a VHE-only configuration
> (E2H is writable, and ID_AA64MMFR0_EL1 is 0), despite the hypervisor's
> best effort to repaint the id register.
>
> Replace the RAO/WI test by a sequence that makes use of the VHE
> register remnapping between EL1 and EL2 to detect this situation,
> and work out whether we get the VHE behaviour even after having
> set HCR_EL2.E2H to 0.
>
> This solves the NV problem, and provides a more reliable acid test
> for CPUs that do not completely follow the letter of the architecture
> while providing a RES1 behaviour for HCR_EL2.E2H.
>
> Suggested-by: Marc Rutland <mark.rutland@arm.com>
^~~~
Thank you *Mark* for the suggestion here, neat trick :)
I'd be in favor of this patch being sent to stable, happy to handle the
backports if you don't have the time for it. VMs mysteriously dying
isn't a very good experience on NV and I'd like to not scare folks away.
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
Thanks,
Oliver
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection
2025-10-09 21:30 ` Oliver Upton
@ 2025-10-10 9:22 ` Marc Zyngier
2025-10-10 9:36 ` Mark Rutland
0 siblings, 1 reply; 10+ messages in thread
From: Marc Zyngier @ 2025-10-10 9:22 UTC (permalink / raw)
To: Oliver Upton
Cc: linux-arm-kernel, kvmarm, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Will Deacon, Catalin Marinas, Mark Rutland, Jan Kotas
On Thu, 09 Oct 2025 22:30:34 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
>
> Hey,
>
> On Thu, Oct 09, 2025 at 01:12:39PM +0100, Marc Zyngier wrote:
> > We currently have two ways to identify CPUs that only implement FEAT_VHE
> > and not FEAT_E2H0:
> >
> > - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
> > - or the HCR_EL2.E2H bit is RAO/WI
> >
> > However, there is a third category of "cpus" that fall between these
> > two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
> > an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
> > is zero.
> >
> > A consequence of this is that on systems such as Neoverse V2, a NV
> > guest cannot reliably detect that it is in a VHE-only configuration
> > (E2H is writable, and ID_AA64MMFR0_EL1 is 0), despite the hypervisor's
> > best effort to repaint the id register.
> >
> > Replace the RAO/WI test by a sequence that makes use of the VHE
> > register remnapping between EL1 and EL2 to detect this situation,
> > and work out whether we get the VHE behaviour even after having
> > set HCR_EL2.E2H to 0.
> >
> > This solves the NV problem, and provides a more reliable acid test
> > for CPUs that do not completely follow the letter of the architecture
> > while providing a RES1 behaviour for HCR_EL2.E2H.
> >
> > Suggested-by: Marc Rutland <mark.rutland@arm.com>
> ^~~~
>
> Thank you *Mark* for the suggestion here, neat trick :)
Too many Mar[ck]s. I'm struggling! ;-)
> I'd be in favor of this patch being sent to stable, happy to handle the
> backports if you don't have the time for it. VMs mysteriously dying
> isn't a very good experience on NV and I'd like to not scare folks away.
I think Mark (yes, him!) had a plan to backport some of the !FEAT_E2H0
patches back to earlier kernels. I'll let him comment on that.
> Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
Thanks!
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection
2025-10-10 9:22 ` Marc Zyngier
@ 2025-10-10 9:36 ` Mark Rutland
2025-10-14 8:53 ` Marc Zyngier
0 siblings, 1 reply; 10+ messages in thread
From: Mark Rutland @ 2025-10-10 9:36 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, linux-arm-kernel, kvmarm, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Will Deacon, Catalin Marinas,
Jan Kotas
On Fri, Oct 10, 2025 at 10:22:18AM +0100, Marc Zyngier wrote:
> On Thu, 09 Oct 2025 22:30:34 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > Hey,
> >
> > On Thu, Oct 09, 2025 at 01:12:39PM +0100, Marc Zyngier wrote:
> > > We currently have two ways to identify CPUs that only implement FEAT_VHE
> > > and not FEAT_E2H0:
> > >
> > > - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
> > > - or the HCR_EL2.E2H bit is RAO/WI
> > >
> > > However, there is a third category of "cpus" that fall between these
> > > two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
> > > an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
> > > is zero.
> > >
> > > A consequence of this is that on systems such as Neoverse V2, a NV
> > > guest cannot reliably detect that it is in a VHE-only configuration
> > > (E2H is writable, and ID_AA64MMFR0_EL1 is 0), despite the hypervisor's
> > > best effort to repaint the id register.
> > >
> > > Replace the RAO/WI test by a sequence that makes use of the VHE
> > > register remnapping between EL1 and EL2 to detect this situation,
> > > and work out whether we get the VHE behaviour even after having
> > > set HCR_EL2.E2H to 0.
> > >
> > > This solves the NV problem, and provides a more reliable acid test
> > > for CPUs that do not completely follow the letter of the architecture
> > > while providing a RES1 behaviour for HCR_EL2.E2H.
> > >
> > > Suggested-by: Marc Rutland <mark.rutland@arm.com>
> > ^~~~
> >
> > Thank you *Mark* for the suggestion here, neat trick :)
>
> Too many Mar[ck]s. I'm struggling! ;-)
Time to file a deed poll. ;)
> > I'd be in favor of this patch being sent to stable, happy to handle the
> > backports if you don't have the time for it. VMs mysteriously dying
> > isn't a very good experience on NV and I'd like to not scare folks away.
>
> I think Mark (yes, him!) had a plan to backport some of the !FEAT_E2H0
> patches back to earlier kernels. I'll let him comment on that.
Yep; I had a (delayed) plan to backport:
https://lore.kernel.org/linux-arm-kernel/20250227180526.1204723-1-mark.rutland@arm.com/
... to v6.12, as folk are trying to run stable/android v6.12 kernels on
models and HW with the RES1 behaviour, and IIRC we didn't try to handle
this at all back in v6.6 (so no need to backport that far). I was
expecting to backport this patch at the same time.
If someone else has the time to do the backport, I'm more than happy to
leave it to them! Otherwise, I was planning to wait for this patch to
land in mainline before starting that.
Mark.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection
2025-10-10 9:36 ` Mark Rutland
@ 2025-10-14 8:53 ` Marc Zyngier
0 siblings, 0 replies; 10+ messages in thread
From: Marc Zyngier @ 2025-10-14 8:53 UTC (permalink / raw)
To: Mark Rutland
Cc: Oliver Upton, linux-arm-kernel, kvmarm, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Will Deacon, Catalin Marinas,
Jan Kotas
On Fri, 10 Oct 2025 10:36:03 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Fri, Oct 10, 2025 at 10:22:18AM +0100, Marc Zyngier wrote:
> > On Thu, 09 Oct 2025 22:30:34 +0100,
> > Oliver Upton <oliver.upton@linux.dev> wrote:
> > >
> > > Hey,
> > >
> > > On Thu, Oct 09, 2025 at 01:12:39PM +0100, Marc Zyngier wrote:
> > > > We currently have two ways to identify CPUs that only implement FEAT_VHE
> > > > and not FEAT_E2H0:
> > > >
> > > > - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
> > > > - or the HCR_EL2.E2H bit is RAO/WI
> > > >
> > > > However, there is a third category of "cpus" that fall between these
> > > > two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
> > > > an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
> > > > is zero.
> > > >
> > > > A consequence of this is that on systems such as Neoverse V2, a NV
> > > > guest cannot reliably detect that it is in a VHE-only configuration
> > > > (E2H is writable, and ID_AA64MMFR0_EL1 is 0), despite the hypervisor's
> > > > best effort to repaint the id register.
> > > >
> > > > Replace the RAO/WI test by a sequence that makes use of the VHE
> > > > register remnapping between EL1 and EL2 to detect this situation,
> > > > and work out whether we get the VHE behaviour even after having
> > > > set HCR_EL2.E2H to 0.
> > > >
> > > > This solves the NV problem, and provides a more reliable acid test
> > > > for CPUs that do not completely follow the letter of the architecture
> > > > while providing a RES1 behaviour for HCR_EL2.E2H.
> > > >
> > > > Suggested-by: Marc Rutland <mark.rutland@arm.com>
> > > ^~~~
> > >
> > > Thank you *Mark* for the suggestion here, neat trick :)
> >
> > Too many Mar[ck]s. I'm struggling! ;-)
>
> Time to file a deed poll. ;)
>
> > > I'd be in favor of this patch being sent to stable, happy to handle the
> > > backports if you don't have the time for it. VMs mysteriously dying
> > > isn't a very good experience on NV and I'd like to not scare folks away.
> >
> > I think Mark (yes, him!) had a plan to backport some of the !FEAT_E2H0
> > patches back to earlier kernels. I'll let him comment on that.
>
> Yep; I had a (delayed) plan to backport:
>
> https://lore.kernel.org/linux-arm-kernel/20250227180526.1204723-1-mark.rutland@arm.com/
>
> ... to v6.12, as folk are trying to run stable/android v6.12 kernels on
> models and HW with the RES1 behaviour, and IIRC we didn't try to handle
> this at all back in v6.6 (so no need to backport that far). I was
> expecting to backport this patch at the same time.
>
> If someone else has the time to do the backport, I'm more than happy to
> leave it to them! Otherwise, I was planning to wait for this patch to
> land in mainline before starting that.
So I've taken the patch as is, without a Cc: stable, because I don't
trust this to be automatically AI-slopped^W^Wbackported to stable, and
the dependency chain isn't in stable either.
Happy to help with that though.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection
2025-10-09 12:12 [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection Marc Zyngier
2025-10-09 13:00 ` Mark Rutland
2025-10-09 21:30 ` Oliver Upton
@ 2025-10-13 11:17 ` Catalin Marinas
2025-10-14 8:49 ` Marc Zyngier
3 siblings, 0 replies; 10+ messages in thread
From: Catalin Marinas @ 2025-10-13 11:17 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, kvmarm, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Will Deacon, Mark Rutland, Jan Kotas
On Thu, Oct 09, 2025 at 01:12:39PM +0100, Marc Zyngier wrote:
> We currently have two ways to identify CPUs that only implement FEAT_VHE
> and not FEAT_E2H0:
>
> - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
> - or the HCR_EL2.E2H bit is RAO/WI
>
> However, there is a third category of "cpus" that fall between these
> two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
> an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
> is zero.
>
> A consequence of this is that on systems such as Neoverse V2, a NV
> guest cannot reliably detect that it is in a VHE-only configuration
> (E2H is writable, and ID_AA64MMFR0_EL1 is 0), despite the hypervisor's
> best effort to repaint the id register.
>
> Replace the RAO/WI test by a sequence that makes use of the VHE
> register remnapping between EL1 and EL2 to detect this situation,
> and work out whether we get the VHE behaviour even after having
> set HCR_EL2.E2H to 0.
>
> This solves the NV problem, and provides a more reliable acid test
> for CPUs that do not completely follow the letter of the architecture
> while providing a RES1 behaviour for HCR_EL2.E2H.
>
> Suggested-by: Marc Rutland <mark.rutland@arm.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/r/15A85F2B-1A0C-4FA7-9FE4-EEC2203CC09E@global.cadence.com
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection
2025-10-09 12:12 [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection Marc Zyngier
` (2 preceding siblings ...)
2025-10-13 11:17 ` Catalin Marinas
@ 2025-10-14 8:49 ` Marc Zyngier
3 siblings, 0 replies; 10+ messages in thread
From: Marc Zyngier @ 2025-10-14 8:49 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, Marc Zyngier
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Will Deacon, Catalin Marinas, Mark Rutland, Jan Kotas
On Thu, 09 Oct 2025 13:12:39 +0100, Marc Zyngier wrote:
> We currently have two ways to identify CPUs that only implement FEAT_VHE
> and not FEAT_E2H0:
>
> - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
> - or the HCR_EL2.E2H bit is RAO/WI
>
> However, there is a third category of "cpus" that fall between these
> two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
> an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
> is zero.
>
> [...]
Applied to fixes, thanks!
[1/1] arm64: Revamp HCR_EL2.E2H RES1 detection
commit: ca88ecdce5f51874a7c151809bd2c936ee0d3805
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 10+ messages in thread