[PATCH v4] armv8: Handle EL2 Host mode

On implementations that support VHE, the layout of the CPTR_EL2 register depends on whether HCR_EL2.E2H is set. If the bit is set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact be accessed through that register. In that case, jump to the EL1 code to enable access to the FP/SIMD registers. This allows U-Boot to run on systems that pass control to U-Boot in EL2 with EL2 Host mode enabled such as machines using Apple's M1 SoC.
Signed-off-by: Mark Kettenis kettenis@openbsd.org ---
v4: use EL1 codepath when HCR_EL2.E2H is set suggested by Marc Zyngier maz@kernel.org
v2: rename label
arch/arm/cpu/armv8/start.S | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 662449156b..9e9c6140cd 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -132,11 +132,13 @@ pie_fixup_done: msr cntfrq_el0, x0 /* Initialize CNTFRQ */ #endif b 0f -2: set_vbar vbar_el2, x0 +2: mrs x1, hcr_el2 + tbnz x1, #34, 1f /* HCR_EL2.E2H */ + set_vbar vbar_el2, x0 mov x0, #0x33ff msr cptr_el2, x0 /* Enable FP/SIMD */ b 0f -1: set_vbar vbar_el1, x0 +1: set_vbar vbar_el1, x0 mov x0, #3 << 20 msr cpacr_el1, x0 /* Enable FP/SIMD */ 0:

On 2021-02-10 19:14, Mark Kettenis wrote:
On implementations that support VHE, the layout of the CPTR_EL2 register depends on whether HCR_EL2.E2H is set. If the bit is set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact be accessed through that register. In that case, jump to the EL1 code to enable access to the FP/SIMD registers. This allows U-Boot to run on systems that pass control to U-Boot in EL2 with EL2 Host mode enabled such as machines using Apple's M1 SoC.
Signed-off-by: Mark Kettenis kettenis@openbsd.org
v4: use EL1 codepath when HCR_EL2.E2H is set suggested by Marc Zyngier maz@kernel.org
v2: rename label
arch/arm/cpu/armv8/start.S | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 662449156b..9e9c6140cd 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -132,11 +132,13 @@ pie_fixup_done: msr cntfrq_el0, x0 /* Initialize CNTFRQ */ #endif
This seems to skip the CNTFRQ_EL0 setup. However, this should probably also be done on CPUs that do not have EL3, such as M1. Unless the lower level FW already deals with it? Doesn't have to be part of this patch though.
b 0f -2: set_vbar vbar_el2, x0 +2: mrs x1, hcr_el2
- tbnz x1, #34, 1f /* HCR_EL2.E2H */
- set_vbar vbar_el2, x0 mov x0, #0x33ff msr cptr_el2, x0 /* Enable FP/SIMD */ b 0f
-1: set_vbar vbar_el1, x0 +1: set_vbar vbar_el1, x0 mov x0, #3 << 20 msr cpacr_el1, x0 /* Enable FP/SIMD */ 0:
This otherwise looks good.
Acked-by: Marc Zyngier maz@kernel.org
M.

Date: Thu, 11 Feb 2021 09:58:49 +0000 From: Marc Zyngier maz@kernel.org
On 2021-02-10 19:14, Mark Kettenis wrote:
On implementations that support VHE, the layout of the CPTR_EL2 register depends on whether HCR_EL2.E2H is set. If the bit is set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact be accessed through that register. In that case, jump to the EL1 code to enable access to the FP/SIMD registers. This allows U-Boot to run on systems that pass control to U-Boot in EL2 with EL2 Host mode enabled such as machines using Apple's M1 SoC.
Signed-off-by: Mark Kettenis kettenis@openbsd.org
v4: use EL1 codepath when HCR_EL2.E2H is set suggested by Marc Zyngier maz@kernel.org
v2: rename label
arch/arm/cpu/armv8/start.S | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 662449156b..9e9c6140cd 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -132,11 +132,13 @@ pie_fixup_done: msr cntfrq_el0, x0 /* Initialize CNTFRQ */ #endif
This seems to skip the CNTFRQ_EL0 setup. However, this should probably also be done on CPUs that do not have EL3, such as M1. Unless the lower level FW already deals with it? Doesn't have to be part of this patch though.
Hi Marc,
I think the basic assumption that U-Boot makes is that if you enter in EL2 or EL1 there is firmware (e.g. TF-A) that does the CNTFRQ_EL0 setup.
On the M1 there is defenitely lower level FW that deals with this, so this assumption is still fine.
b 0f -2: set_vbar vbar_el2, x0 +2: mrs x1, hcr_el2
- tbnz x1, #34, 1f /* HCR_EL2.E2H */
- set_vbar vbar_el2, x0 mov x0, #0x33ff msr cptr_el2, x0 /* Enable FP/SIMD */ b 0f
-1: set_vbar vbar_el1, x0 +1: set_vbar vbar_el1, x0 mov x0, #3 << 20 msr cpacr_el1, x0 /* Enable FP/SIMD */ 0:
This otherwise looks good.
Acked-by: Marc Zyngier maz@kernel.org
M.
-- Jazz is not dead. It just smells funny...

Hi Mark,
On 2021-02-11 10:22, Mark Kettenis wrote:
Date: Thu, 11 Feb 2021 09:58:49 +0000 From: Marc Zyngier maz@kernel.org
On 2021-02-10 19:14, Mark Kettenis wrote:
On implementations that support VHE, the layout of the CPTR_EL2 register depends on whether HCR_EL2.E2H is set. If the bit is set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact be accessed through that register. In that case, jump to the EL1 code to enable access to the FP/SIMD registers. This allows U-Boot to run on systems that pass control to U-Boot in EL2 with EL2 Host mode enabled such as machines using Apple's M1 SoC.
Signed-off-by: Mark Kettenis kettenis@openbsd.org
v4: use EL1 codepath when HCR_EL2.E2H is set suggested by Marc Zyngier maz@kernel.org
v2: rename label
arch/arm/cpu/armv8/start.S | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 662449156b..9e9c6140cd 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -132,11 +132,13 @@ pie_fixup_done: msr cntfrq_el0, x0 /* Initialize CNTFRQ */ #endif
This seems to skip the CNTFRQ_EL0 setup. However, this should probably also be done on CPUs that do not have EL3, such as M1. Unless the lower level FW already deals with it? Doesn't have to be part of this patch though.
Hi Marc,
I think the basic assumption that U-Boot makes is that if you enter in EL2 or EL1 there is firmware (e.g. TF-A) that does the CNTFRQ_EL0 setup.
On the M1 there is defenitely lower level FW that deals with this, so this assumption is still fine.
Right. As long as CNTFRQ_EL0 gets set to the correct value on all CPUs, I'm happy!
Thanks,
M.

On Wed, Feb 10, 2021 at 08:14:55PM +0100, Mark Kettenis wrote:
On implementations that support VHE, the layout of the CPTR_EL2 register depends on whether HCR_EL2.E2H is set. If the bit is set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact be accessed through that register. In that case, jump to the EL1 code to enable access to the FP/SIMD registers. This allows U-Boot to run on systems that pass control to U-Boot in EL2 with EL2 Host mode enabled such as machines using Apple's M1 SoC.
Signed-off-by: Mark Kettenis kettenis@openbsd.org Acked-by: Marc Zyngier maz@kernel.org
Applied to u-boot/master, thanks!
participants (4)
-
Marc Zyngier
-
Mark Kettenis
-
Mark Kettenis
-
Tom Rini