Re: [PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection

[Marc Zyngier <maz@kernel.org>]

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.