[PATCH v4] armv8: Handle EL2 Host mode

[PATCH v4] armv8: Handle EL2 Host mode

[Mark Kettenis]

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

[PATCH v4] armv8: Handle EL2 Host mode

[Marc Zyngier]

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.
-- 
Jazz is not dead. It just smells funny...

[PATCH v4] armv8: Handle EL2 Host mode

[Mark Kettenis]

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

[PATCH v4] armv8: Handle EL2 Host mode

[Marc Zyngier]

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.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v4] armv8: Handle EL2 Host mode

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

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!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]