Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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/
>>



      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