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

From: Fuad Tabba

Date: Wed Aug 26 2026 - 18:09:26 EST


Hi Ben,

On Wed, 26 Aug 2026 at 15:48, Ben Horgan <ben.horgan@xxxxxxx> wrote:
...
> > 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.

Marc's "Fully disable configured-out features" series [1] runs into
this too. MPAM may be the family member EL2 cannot put into a defined
state on its own.

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

Documentation it is, I'm afraid... :)

Is there any way to find out what MPAM3_EL3.TRAPLOWER is set to? If
not, could the caveat go the other way round: arm64.nompam is for
systems where firmware ignores MPAM, and should only be set on a
machine that does not boot without it?

__activate_traps_mpam() is gated on the same ID fields the override
clears, so KVM stops trapping guest accesses to MPAM0_EL1, MPAM1_EL1
and MPAMIDR_EL1, while still hiding the ID field.

I will send a patch for Documentation/arch/arm64/mpam.rst, unless you
or James think it belongs elsewhere.

Cheers,
/fuad

[1] https://lore.kernel.org/all/20260302115653.1517326-1-maz@xxxxxxxxxx/


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