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

[Mark Rutland <mark.rutland@arm.com>]

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
> 
>