Re: [boot-wrapper 2/3] aarch64: Enable access into SCTLR2_ELx registers from EL2 and below

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

On Tue, Jul 23, 2024 at 04:36:29PM +0530, Anshuman Khandual wrote:
> FEAT_SCTLR2 adds SCTLR2_EL1 and SCTLR2_EL2 system registers But access into
> these register from EL2 and below trap to EL3 unless SCR_EL3.D128En is set.
> 
> Enable access to SCTLR2_ELx registers when they are implemented.
> 
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>

I think this should be first in the series, since SCTLR2 can exist
without D128, but not vice-versa.

> ---
>  arch/aarch64/include/asm/cpu.h | 4 +++-
>  arch/aarch64/init.c            | 3 +++
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/aarch64/include/asm/cpu.h b/arch/aarch64/include/asm/cpu.h
> index 0b8b463..57d66e4 100644
> --- a/arch/aarch64/include/asm/cpu.h
> +++ b/arch/aarch64/include/asm/cpu.h
> @@ -56,6 +56,7 @@
>  #define SCR_EL3_HXEn			BIT(38)
>  #define SCR_EL3_EnTP2			BIT(41)
>  #define SCR_EL3_TCR2EN			BIT(43)
> +#define SCR_EL3_SCTLR2En		BIT(44)
>  #define SCR_EL3_PIEN			BIT(45)
>  #define SCR_EL3_D128En			BIT(47)
>  
> @@ -81,7 +82,8 @@
>  
>  #define ID_AA64MMFR1_EL1_HCX		BITS(43, 40)
>  
> -#define ID_AA64MMFR3_EL1_TCRX		BITS(4, 0)
> +#define ID_AA64MMFR3_EL1_TCRX		BITS(3, 0)
> +#define ID_AA64MMFR3_EL1_SCTLRX		BITS(7, 4)
>  #define ID_AA64MMFR3_EL1_S1PIE		BITS(11, 8)
>  #define ID_AA64MMFR3_EL1_S2PIE		BITS(15, 12)
>  #define ID_AA64MMFR3_EL1_S1POE		BITS(19, 16)
> diff --git a/arch/aarch64/init.c b/arch/aarch64/init.c
> index 7d9d0d9..5b21cb8 100644
> --- a/arch/aarch64/init.c
> +++ b/arch/aarch64/init.c
> @@ -92,6 +92,9 @@ void cpu_init_el3(void)
>  	if (mrs_field(ID_AA64MMFR3_EL1, D128))
>  		scr |= SCR_EL3_D128En;
>  
> +	if (mrs_field(ID_AA64MMFR3_EL1, SCTLRX))
> +		scr |= SCR_EL3_SCTLR2En;
> +

The SCTLR2_ELx registers reset to UNKNOWN values when the highest
implemented exception level is not ELx, so we need to initialize those
to safe values. Otherwise a kernel which is not aware of SCTLR2_ELx will
be subject to arbitrary behaviour as a result of the SCTLR2_ELx bits
which it will not have configured.

I know that we've failed to do that for other things (FGT and HCRX), and
those are latent bugs / mistakes in our appraoch that I'll see about
fixing.

Mark.