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

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

[Fuad Tabba]

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.

Cheers,
/fuad

[1] https://lore.kernel.org/all/20260825164219.3347229-1-fuad.tabba@linux.dev/

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@linux.dev/

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

[Fuad Tabba]

Hi Ben,

On Wed, 26 Aug 2026 at 15:48, Ben Horgan <ben.horgan@arm.com> 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@kernel.org/


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

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

[Ben Horgan]

Hi Fuad,

On 26/08/2026 23:08, Fuad Tabba wrote:
> Hi Ben,
> 
> On Wed, 26 Aug 2026 at 15:48, Ben Horgan <ben.horgan@arm.com> 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?

No

 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?

Yes, seems fine.

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

Thanks! Ok with me assuming you also add a reference in
Documentation/admin-guide/kernel-parameters.txt, e.g. "See Documentation/arch/arm64/mpam.rst".

Ben

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