From: Ben Horgan <ben.horgan@arm.com>
To: Fuad Tabba <fuad.tabba@linux.dev>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
James Morse <james.morse@arm.com>, Xi Ruoyao <xry111@xry111.site>,
Marc Zyngier <maz@kernel.org>,
Bradley Morgan <brads@mainlining.org>,
Fuad Tabba <tabba@google.com>,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] arm64: mpam: Document when to set arm64.nompam
Date: Mon, 7 Sep 2026 10:44:23 +0100 [thread overview]
Message-ID: <966b103e-dc9e-479a-ba6c-e8e6727e1bd7@arm.com> (raw)
In-Reply-To: <20260904103131.627392-1-fuad.tabba@linux.dev>
Hi Fuad,
On 04/09/2026 11:31, Fuad Tabba wrote:
> arm64.nompam skips the MPAM2_EL2 and MPAMHCR_EL2 writes in
> finalise_el2_state and leaves the ARM64_MPAM cpucap unset. Where EL3
> firmware has cleared MPAM3_EL3.TRAPLOWER, the EL2 trap controls are
> left unwritten, at reset values that are UNKNOWN, and KVM still hides
> MPAM from the guest but no longer enables the traps that stop a guest
> from using it. KVM never saves or restores MPAM0_EL1 and MPAM1_EL1, so
> what one guest writes reaches the next guest and the host. Nor can the
> kernel make the EL2 writes unconditionally: they trap to EL3 on the
> firmware the option exists for, and TRAPLOWER cannot be read below EL3.
>
> Say so in mpam.rst, and add the rule and a pointer to the
> kernel-parameters entry.
>
> Suggested-by: Ben Horgan <ben.horgan@arm.com>
> Link: https://lore.kernel.org/all/CA+EHjTxeWxZiuSmnKLGLxTBXP4oJT7-LuffbPAyCSZZ5TW=5Ew@mail.gmail.com/
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> ---
>
> Notes:
> Changes since v1, the first three from Ben Horgan's review:
> - Put arm64.nompam under a new "Command line parameters" section.
> - Separate MPAM3_EL3.MPAMEN from TRAPLOWER, which v1 conflated.
> - Add that KVM does not save or restore MPAM0_EL1 and MPAM1_EL1.
> - Drop "No functional change intended." from the commit message.
>
> Bradley Morgan's Reviewed-by on v1 is not carried over: both
> paragraphs, the section heading and the commit message changed.
>
> v1: https://lore.kernel.org/all/20260903084809.2027326-1-fuad.tabba@linux.dev/
>
> .../admin-guide/kernel-parameters.txt | 3 ++-
> Documentation/arch/arm64/mpam.rst | 25 +++++++++++++++++++
> 2 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 68647ff4bdd24..e6d543de3cde5 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -575,7 +575,8 @@ Kernel parameters
> Set instructions support
>
> arm64.nompam [ARM64] Unconditionally disable Memory Partitioning And
> - Monitoring support
> + Monitoring support. Only for a machine that does not
> + boot without it. See Documentation/arch/arm64/mpam.rst
>
> arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension
> support
> diff --git a/Documentation/arch/arm64/mpam.rst b/Documentation/arch/arm64/mpam.rst
> index 67fe515ed501c..e66b1359d1282 100644
> --- a/Documentation/arch/arm64/mpam.rst
> +++ b/Documentation/arch/arm64/mpam.rst
> @@ -87,6 +87,31 @@ The supported features are:
> MBWU monitors can be exposed to the user after support for more monitoring
> scopes is added to resctrl.
>
> +Command line parameters
> +=======================
> +
> +arm64.nompam
> +------------
> +Firmware controls MPAM through two bits of MPAM3_EL3. MPAMEN enables
> +it: while set, the PARTID and PMG in the MPAMn_ELx registers label the
> +CPU's memory requests. TRAPLOWER, which resets to 1, traps accesses to
> +the MPAM system registers from the lower exception levels to EL3.
> +Firmware must clear it, or handle the trap and emulate MPAM as disabled.
> +Where it does neither, the CPUs still advertise MPAM in the ID registers,
> +the kernel's MPAM register accesses trap to EL3, and the boot fails.
> +``arm64.nompam`` exists for that firmware: it makes the kernel treat the
> +CPUs as not implementing MPAM, so no MPAM system register is accessed.
> +Set it only on a machine that does not boot without it.
> +
> +It is not a way to turn MPAM off. Where firmware has cleared TRAPLOWER,
> +the option leaves the trap controls in MPAM2_EL2 and MPAMHCR_EL2
> +unwritten, and their reset values are UNKNOWN. KVM still hides MPAM from
> +guests but no longer enables the traps that stop a guest from using it,
> +so a guest may be able to read and write MPAM0_EL1 and MPAM1_EL1. KVM
As you are listing registers, MPAMSM_EL1 can go here too.
Generally, I think this documentation change looks good now but holding off on a tag for the moment
in case anything comes up from your MPAM trapping change [1].
[1] https://lore.kernel.org/linux-arm-kernel/20260903160819.831518-1-fuad.tabba@linux.dev/
Thanks,
Ben
> +does not save or restore them, so what one guest writes is still there
> +when the next guest runs on that CPU, and when the host does. With MPAMEN
> +set, EL0 and EL1 requests then carry that PARTID and PMG.
> +
> Reporting Bugs
> ==============
> If you are not seeing the counters or controls you expect please share the
next prev parent reply other threads:[~2026-09-07 9:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 10:31 [PATCH v2] arm64: mpam: Document when to set arm64.nompam Fuad Tabba
2026-09-04 10:35 ` Bradley Morgan
2026-09-07 9:44 ` Ben Horgan [this message]
2026-09-07 10:35 ` Fuad Tabba
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=966b103e-dc9e-479a-ba6c-e8e6727e1bd7@arm.com \
--to=ben.horgan@arm.com \
--cc=brads@mainlining.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=fuad.tabba@linux.dev \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
--cc=tabba@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.