Commit 3944382f authored by Marc Zyngier's avatar Marc Zyngier Committed by Oliver Upton
Browse files

arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative 



For CPUs that have ID_AA64MMFR4_EL1.E2H0 as negative, it is important
to avoid the boot path that sets HCR_EL2.E2H=0. Fortunately, we
already have this path to cope with fruity CPUs.

Tweak init_el2 to look at ID_AA64MMFR4_EL1.E2H0 first.

Reviewed-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20240122181344.258974-8-maz@kernel.org


Signed-off-by: default avatarOliver Upton <oliver.upton@linux.dev>
parent da9af507

arch/arm64/kernel/head.S

+15 −8
Original line number Diff line number Diff line
@@ -584,25 +584,32 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL) 
	mov_q	x1, INIT_SCTLR_EL1_MMU_OFF



	/*

	 * Fruity CPUs seem to have HCR_EL2.E2H set to RES1,

	 * making it impossible to start in nVHE mode. Is that

	 * compliant with the architecture? Absolutely not!

	 * Compliant CPUs advertise their VHE-onlyness with

	 * ID_AA64MMFR4_EL1.E2H0 < 0. HCR_EL2.E2H can be

	 * RES1 in that case.

	 *

	 * Fruity CPUs seem to have HCR_EL2.E2H set to RES1, but

	 * don't advertise it (they predate this relaxation).

	 */

	mrs_s	x0, SYS_ID_AA64MMFR4_EL1

	ubfx	x0, x0, #ID_AA64MMFR4_EL1_E2H0_SHIFT, #ID_AA64MMFR4_EL1_E2H0_WIDTH

	tbnz	x0, #(ID_AA64MMFR4_EL1_E2H0_SHIFT + ID_AA64MMFR4_EL1_E2H0_WIDTH - 1), 1f



	mrs	x0, hcr_el2

	and	x0, x0, #HCR_E2H

	cbz	x0, 1f



	cbz	x0, 2f

1:

	/* Set a sane SCTLR_EL1, the VHE way */

	pre_disable_mmu_workaround

	msr_s	SYS_SCTLR_EL12, x1

	mov	x2, #BOOT_CPU_FLAG_E2H

	b	2f

	b	3f



1:

2:

	pre_disable_mmu_workaround

	msr	sctlr_el1, x1

	mov	x2, xzr

2:

3:

	__init_el2_nvhe_prepare_eret



	mov	w0, #BOOT_CPU_MODE_EL2