[boot-wrapper PATCH 1/4] aarch64: do not trap MPAM register accesses

[Dave Martin]

Hi Andre,

On Wed, Oct 22, 2025 at 11:25:00AM +0100, Andre Przywara wrote:
> The architectural MPAM system registers in lower ELs are controlled by
> an EL3 control bit. To allow access to registers like MPAM2_EL2 or
> MPAM_EL1, clear the TRAPLOWER bit in the MPAM3_EL3 system register, to
> avoid an unhandled trap into the boot-wrapper code.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  arch/aarch64/include/asm/cpu.h | 4 ++++
>  arch/aarch64/init.c            | 3 +++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/aarch64/include/asm/cpu.h b/arch/aarch64/include/asm/cpu.h
> index ac50474..0f6e2ce 100644
> --- a/arch/aarch64/include/asm/cpu.h
> +++ b/arch/aarch64/include/asm/cpu.h
> @@ -29,6 +29,9 @@
>  #define HFGWTR2_EL2		s3_4_c3_c1_3
>  #define HFGITR2_EL2		s3_4_c3_c1_7
>  
> +#define MPAM3_EL3		s3_6_c10_c5_0
> +#define MPAM3_EL3_TRAPLOWER	BIT(62)
> +
>  /*
>   * RES1 bit definitions definitions as of ARM DDI 0487G.b
>   *
> @@ -120,6 +123,7 @@
>  
>  #define ID_AA64PFR0_EL1_RAS		BITS(31, 28)
>  #define ID_AA64PFR0_EL1_SVE		BITS(35, 32)
> +#define ID_AA64PFR0_EL1_MPAM		BITS(43, 40)
>  #define ID_AA64PFR0_EL1_CSV2		BITS(59, 56)
>  
>  #define ID_AA64PFR1_EL1_MTE		BITS(11, 8)
> diff --git a/arch/aarch64/init.c b/arch/aarch64/init.c
> index cb24f4e..99e43cf 100644
> --- a/arch/aarch64/init.c
> +++ b/arch/aarch64/init.c
> @@ -198,6 +198,9 @@ static void cpu_init_el3(void)
>  
>  		msr(SMCR_EL3, smcr);
>  	}
> +
> +	if (mrs_field(ID_AA64PFR0_EL1, MPAM))
> +		msr(MPAM3_EL3, mrs(MPAM3_EL3) & ~MPAM3_EL3_TRAPLOWER);
>  }

This enables register access to the MPAM-related CPU regs for lower ELs,
but doesn't fully enable MPAM.

There is a global switch to turn MPAM on (MPAMn_ELn.MPAMEN, where ELn
is the highest implemented EL).  It defaults to off, and lower ELs
can't turn it on.  Because it's off by default, most other CPU state
relating to MPAM is not in a defined state out of reset.


...So, I suspect we may need more steps here if we want MPAM to be
usable.

The platform should initialise resource controls in the memory system
for PARTID 0 in a sensible way without software having to do anything,
but we have to make sure that EL3 uses this PARTID and not something
random, and make lower ELs start out using it.  So, probably:

 	MPAM3_EL3.{PARTID,PMG}_{I,D} should be initialised to 0.
 	MPAM2_EL2.{PARTID,PMG}_{I,D} should be initialised to 0.

(Do we ever run the payload directly at EL1?  Hopefully not, but tf so
then we would need to initialise the IDs in MPAM1_EL1 also, and
initialise trap controls in MPAM2_EL2 and MPAMHCR_EL2 and make sure
that PARTID virtualisation controls are off in MPAMHCR_EL2.)

Many other controls require platform-specific knowledge in order to know
how to initialise them sensibly, even though the architecture resets
them to junk.

Since the bootwrapper is not attempting to define a security boundary,
it is probably reasonable to hand everything over to Non-secure, so far
as possible, so in MPAM3_EL3:

	SDEFLT should probably be 0.  (*)
	FORCE_NS should probably be 0.  (*)
	ALTSP_HEN should probably be 1.  (*; James might have a view.)
	ALTSP_EL3 should probably by 0, or left untouched  (*)(+)

(*) Feature-dependent -- in some cases the features that they depend on
have already been declared obsolete, but hopefully we can trust the
architects not to recycle the bits for other purposes.  I'm not sure
what the usual policy is on that.

(+) Architectural reset is IMP DEF.  So maybe it's something sane and
appropriate for the platform but then again, maybe not.

Then:

	ISB

and

	Initialise MPAM3_EL3.MPAMEN to 1.

(This is a global control.  Lower ELs can't turn it on for themselves,
but without it, IDs that they specify in MPAMx_ELx are ignored and
squashed to 0.)

The architecture says that MCSs out in the system will be initialised
with a sensible resource control configuration for PARTID 0.
We probably just have to trust that, otherwise we're in a world of
pain.


I can't promise that I haven't missed some stuff, here!

Cheers
---Dave