arm64: mpam: Document when to set arm64.nompam
Subsystems (3)
PATCH 1/1 arm64: mpam: Document when to set arm64.nompam
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 enabled MPAM, 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. The kernel cannot restore the writes: they trap to EL3 on the firmware the option exists for, and MPAM3_EL3.TRAPLOWER cannot be read below EL3.
Say so in mpam.rst, and add the rule and a pointer to the kernel-parameters entry.
No functional change intended.
--- Documentation/admin-guide/kernel-parameters.txt | 3 ++- Documentation/arch/arm64/mpam.rst | 17 +++++++++++++++++ 2 files changed, 19 insertions(+), 1 deletion(-)
Documentation/admin-guide/kernel-parameters.txt +2 -1
@@ -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
Documentation/arch/arm64/mpam.rst +17 -0
@@ -87,6 +87,23 @@ The supported features are: MBWU monitors can be exposed to the user after support for more monitoring scopes is added to resctrl. +arm64.nompam +============ +Firmware must enable MPAM at the highest implemented exception level and +leave the MPAM system registers accessible to the kernel, or trap the +accesses and emulate MPAM as disabled. Where it does neither, the CPUs +still advertise MPAM in the ID registers, the first kernel access to an +MPAM register traps 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. On a system whose firmware has enabled +MPAM at EL3, 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 choose its own PARTID and PMG. + Reporting Bugs ============== If you are not seeing the counters or controls you expect please share the
Signature · 1 line
2.39.5
Quoted 8 lines · Fuad Tabba
arm64.nompam skips the
MPAM2_EL2andMPAMHCR_EL2writes infinalise_el2_stateand leaves theARM64_MPAMcpucap unset. Where EL3 firmware has enabled MPAM, 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. The kernel cannot restore the writes: they trap to EL3 on the firmware the option exists for, and MPAM3_EL3.TRAPLOWER cannot be read below EL3.
Quoted 7 lines
Say so in
mpam.rst, and add the rule and a pointer to the kernel-parameters entry.No functional change intended.
LGTM, cheers
Quoted 45 lines
Signed-off-by Fuad Tabba <[email protected]>---
Documentation/admin-guide/kernel-parameters.txt| 3 ++-Documentation/arch/arm64/mpam.rst| 17 +++++++++++++++++2 files changed, 19 insertions(+), 1 deletion(-)Documentation/admin-guide/kernel-parameters.txt +2
-1@@ -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 supportDocumentation/arch/arm64/mpam.rst +17
-0@@ -87,6 +87,23 @@ The supported features are: MBWU monitors can be exposed to the user after support for more monitoring scopes is added to resctrl. +arm64.nompam +============ +Firmware must enable MPAM at the highest implemented exception level and +leave the MPAM system registers accessible to the kernel, or trap the +accesses and emulate MPAM as disabled. Where it does neither, the CPUs +still advertise MPAM in the ID registers, the first kernel access to an +MPAM register traps 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. On a system whose firmware has enabled +MPAM at EL3, 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 choose its own PARTID and PMG. +
Quoted 5 lines
Reporting Bugs
==============
If you are not seeing the counters or controls you expect please share the
Ben Horgan
maintainerHi Fuad,
Quoted 40 lines · Fuad Tabba
arm64.nompam skips the
MPAM2_EL2andMPAMHCR_EL2writes infinalise_el2_stateand leaves theARM64_MPAMcpucap unset. Where EL3 firmware has enabled MPAM, 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. The kernel cannot restore the writes: they trap to EL3 on the firmware the option exists for, and MPAM3_EL3.TRAPLOWER cannot be read below EL3.Say so in
mpam.rst, and add the rule and a pointer to the kernel-parameters entry.No functional change intended.
Suggested-by Ben Horgan <[email protected]>Link https://lore.kernel.org/all/CA+EHjTxeWxZiuSmnKLGLxTBXP4oJT7-LuffbPAyCSZZ5TW=5Ew@mail.gmail.com/ open hereSigned-off-by Fuad Tabba <[email protected]>--- Documentation/admin-guide/kernel-parameters.txt | 3 ++- Documentation/arch/arm64/mpam.rst | 17 +++++++++++++++++ 2 files changed, 19 insertions(+), 1 deletion(-)Documentation/admin-guide/kernel-parameters.txt +2
-1@@ -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 supportDocumentation/arch/arm64/mpam.rst +0
-0
Documentation/arch/arm64/mpam.rst The supported features are: · line 91
Quoted 5 lines
Documentation/arch/arm64/mpam.rst +2
-0@@ -87,6 +87,23 @@ The supported features are: MBWU monitors can be exposed to the user after support for more monitoring scopes is added to resctrl. +arm64.nompam +============
This assumes that the reader already knows or can guess that arm64.nompam is a command line parameter. Perhaps the section name can be 'Command line parameters' with a single 'arm64.nompam' subsection underneath or all in the section name.
Documentation/arch/arm64/mpam.rst The supported features are:
Quoted 11 lines
Documentation/arch/arm64/mpam.rst +11
-0+Firmware must enable MPAM at the highest implemented exception level and +leave the MPAM system registers accessible to the kernel, or trap the +accesses and emulate MPAM as disabled. Where it does neither, the CPUs +still advertise MPAM in the ID registers, the first kernel access to an +MPAM register traps 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. On a system whose firmware has enabled +MPAM at EL3, the option leaves the trap controls in MPAM2_EL2 and> +MPAMHCR_EL2 unwritten, and their reset values are UNKNOWN.
Enabling MPAM at EL3 is separate from disabling traps. Setting MPAM3_EL3.MPAMEN to 1 means that the values in MPAMn_ELx are used to determine the PARTID and PMG for CPU requests. At this point EL3 can configure the PARTID and PMG for the different exception levels and MPAM can be used in the system under firmware control. Setting MPAM3_EL3.TRAPLOWER to 0 is what enables EL2 to access the MPAM registers without trapping and configure the traps for MPAM register accesses at EL1.
Documentation/arch/arm64/mpam.rst The supported features are: · line 105
Quoted 4 lines
KVM still
Documentation/arch/arm64/mpam.rst +2
-0+hides MPAM from guests but no longer enables the traps that stop a guest +from using it, so a guest may be able to choose its own PARTID and PMG.
Shouldn't this also mention that the MPAM_*_EL1 are not save restored and so if the traps aren't enabled provide a side channel between guests.
Thanks,
Ben
Quoted 3 lines
Reporting Bugs
==============
If you are not seeing the counters or controls you expect please share the
Hi Ben,
On Thu, 3 Sept 2026 at 10:55, Ben Horgan <[email protected]> wrote:
...
Quoted 6 lines
Quoted 2 lines
+arm64.nompam
+============This assumes that the reader already knows or can guess that arm64.nompam is a command line parameter. Perhaps the section name can be 'Command line parameters' with a single 'arm64.nompam' subsection underneath or all in the section name.
Will do: a "Command line parameters" section with arm64.nompam as its subsection.
Quoted 10 lines
Quoted 10 lines
Documentation/arch/arm64/mpam.rst +9
-0+Firmware must enable MPAM at the highest implemented exception level and +leave the MPAM system registers accessible to the kernel, or trap the +accesses and emulate MPAM as disabled. Where it does neither, the CPUs +still advertise MPAM in the ID registers, the first kernel access to an +MPAM register traps 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. +
Quoted 8 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+It is not a way to turn MPAM off. On a system whose firmware has enabled +MPAM at EL3, the option leaves the trap controls in MPAM2_EL2 and> +MPAMHCR_EL2 unwritten, and their reset values are UNKNOWN.Enabling MPAM at EL3 is separate from disabling traps. Setting MPAM3_EL3.MPAMEN to 1 means that the values in
MPAMn_ELxare used to determine the PARTID and PMG for CPU requests. At this point EL3 can configure the PARTID and PMG for the different exception levels and MPAM can be used in the system under firmware control. Setting MPAM3_EL3.TRAPLOWER to 0 is what enables EL2 to access the MPAM registers without trapping and configure the traps for MPAM register accesses at EL1.
Thanks, I'll separate the two: TRAPLOWER being clear is what leaves the EL2 trap controls unwritten, and MPAMEN is what makes a guest's choice of PARTID and PMG take effect.
Quoted 6 lines
Documentation/arch/arm64/mpam.rst The supported features are: · line 105
Quoted 4 lines
KVM still
Documentation/arch/arm64/mpam.rst +2
-0+hides MPAM from guests but no longer enables the traps that stop a guest +from using it, so a guest may be able to choose its own PARTID and PMG.Shouldn't this also mention that the MPAM_*_EL1 are not save restored and so if the traps aren't enabled provide a side channel between guests.
Yes, I'll add that KVM does not save or restore MPAM0_EL1 and MPAM1_EL1, so what one guest writes is still there for the next guest on that CPU.
I'll send a v2 with these once others have had a chance to comment as well.
Cheers,
/fuad
Quoted 8 lines
Thanks,
Ben
Quoted 3 lines
Reporting Bugs
==============
If you are not seeing the counters or controls you expect please share the