Re: arm64: MPAM2_EL2 and MPAMHCR_EL2 are left UNKNOWN under arm64.nompam

[Ben Horgan]

Hi Fuad,

On 25/08/2026 20:18, Fuad Tabba wrote:
> Hi Xi, James, Catalin, Will,
> 
> I'm going through the features that can be disabled on the host
> command line, checking that EL2 either traps them or leaves its own
> controls in a defined state. That quick and easy GMID_EL1 fix came out
> of the same pass [1] :)
> 
> Since 10f885d63a0e ("arm64: Add override for MPAM"), arm64.nompam
> skips the MPAM2_EL2 and MPAMHCR_EL2 writes in finalise_el2_state, so
> on an MPAM PE with EL3 implemented the trap controls in both keep
> their reset values, which are architecturally UNKNOWN.
> 
> I was wondering whether that was deliberate. AFAICT, restoring the
> writes would trap to EL3 wherever MPAM3_EL3.TRAPLOWER is still set, so
> it may not be safe on the machines the override was added for. I have
> a patch restoring them, but I learned my lesson.

Yes, on a system where the firmware ignores MPAM, MPAM3_EL3.TRAPLOWER will be 1 and the traps won't
handled and so if MPAM2_EL2 or MPAMHCR_EL2 are touched to disable the traps then the f/w will panic.
As you say, if arm64.nompam is set on a platform where f/w has cleared MPAM3_EL3.TRAPLOWER to 0 then
the MPAM registers may or not trap . This is different from other features because the EL2 register
than configures the traps is MPAM specific and not in a generic register e.g. CPTR_EL2.

There seems to be no way round this other than documenting that you should only set arm64.nompam if
you are sure that MPAM3_El3.TRAPLOWER is 1 as you otherwise have a side channel. What do you think?

Thanks,

Ben


> 
> Cheers,
> /fuad
> 
> [1] https://lore.kernel.org/all/20260825164219.3347229-1-fuad.tabba@xxxxxxxxx/