From: Ben Horgan <ben.horgan@arm.com>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Xi Ruoyao <xry111@xry111.site>, James Morse <james.morse@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
"moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)"
<linux-arm-kernel@lists.infradead.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: arm64: MPAM2_EL2 and MPAMHCR_EL2 are left UNKNOWN under arm64.nompam
Date: Thu, 27 Aug 2026 09:41:09 +0100 [thread overview]
Message-ID: <0b2c58d2-cc82-4c68-aaa2-83449d0b48c1@arm.com> (raw)
In-Reply-To: <CA+EHjTy0jCbEb0K7Sd_+X-Ly_6fC3vuPxmyTVRkqkF_DAFMucA@mail.gmail.com>
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/
>>
prev parent reply other threads:[~2026-08-27 8:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 19:18 arm64: MPAM2_EL2 and MPAMHCR_EL2 are left UNKNOWN under arm64.nompam Fuad Tabba
2026-08-26 14:48 ` Ben Horgan
2026-08-26 22:08 ` Fuad Tabba
2026-08-27 8:41 ` Ben Horgan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0b2c58d2-cc82-4c68-aaa2-83449d0b48c1@arm.com \
--to=ben.horgan@arm.com \
--cc=catalin.marinas@arm.com \
--cc=fuad.tabba@linux.dev \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=will@kernel.org \
--cc=xry111@xry111.site \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox