KVM: arm64: Trap guest MPAM accesses whenever MPAM is implemented

finalise_el2_state() clears the EL2 MPAM traps whenever the ID registers advertise MPAM, while KVM sets them only under ARM64_MPAM, which also requires MPAMEN. Without EL3 nothing sets that enable, so a guest reaches the MPAM registers while ID_AA64PFR0_EL1.MPAM reads 0 for it.

Gate the traps on the ID registers alone: MPAMEN isn't a term in any MPAM accessor, so they take effect without it. The cap tests the sanitised ID fields, which never exceed a CPU's own, so it's set only where finalise_el2_state already wrote MPAM2_EL2. MPAM3_EL3.TRAPLOWER is clear there, and arm64.nompam turns the cap off too.

Fixes 23b33d1e168c ("arm64: head.S: Initialise MPAM EL2 registers and disable traps")

Reviewed-by Yuan Yao <[email protected]>

Signed-off-by Fuad Tabba <[email protected]>

---

Notes:
Changes since v1:
- Commit message only. The code is unchanged, so Yuan Yao's Reviewed-by is carried.
- Fixes: names the commit that cleared the traps, rather than the one that added KVM's trapping.
- Says why the sanitised ID fields are the safe gate: the cap is set only where finalise_el2_state already wrote MPAM2_EL2.

Not covered, and answered on the v1 thread: a machine whose CPUs differ on MPAM, raised by Ben and by sashiko.

v1: https://lore.kernel.org/all/[email protected]/

 arch/arm64/include/asm/cpufeature.h     |  5 +++++
 arch/arm64/kernel/cpufeature.c          | 13 +++++++++++++
 arch/arm64/kvm/hyp/include/hyp/switch.h |  4 ++--
 arch/arm64/tools/cpucaps                |  1 +
 4 files changed, 21 insertions(+), 2 deletions(-)

arch/arm64/include/asm/cpufeature.h +5 -0

index 7404a6e83a930..8863ae99596bc 100644
@@ -873,6 +873,11 @@ static __always_inline bool system_supports_mpam_hcr(void)
 	return alternative_has_cap_unlikely(ARM64_MPAM_HCR);
 }
 
+static __always_inline bool system_supports_mpam_sysregs(void)
+{
+	return alternative_has_cap_unlikely(ARM64_MPAM_SYSREGS);
+}
+
 static inline bool system_supports_pmuv3(void)
 {
 	return cpus_have_final_cap(ARM64_HAS_PMUV3);

arch/arm64/kernel/cpufeature.c +7 -0

index 17b83a2518a8f..36a27692e5cf7 100644
@@ -2501,6 +2501,13 @@ test_has_mpam(const struct arm64_cpu_capabilities *entry, int scope)
 	return (read_sysreg_s(SYS_MPAM1_EL1) & MPAM1_EL1_MPAMEN);
 }
 
+static bool
+test_has_mpam_sysregs(const struct arm64_cpu_capabilities *entry, int __unused)
+{
+	/* The registers exist whether or not firmware enabled MPAM. */
+	return detect_ftr_has_mpam();
+}
+
 static void
 cpu_enable_mpam(const struct arm64_cpu_capabilities *entry)
 {

Quoted 11 lines

arch/arm64/kernel/cpufeature.c +7 -0

+static bool
+test_has_mpam_sysregs(const struct arm64_cpu_capabilities *entry, int __unused)
+{
+     /* The registers exist whether or not firmware enabled MPAM. */
+     return detect_ftr_has_mpam();
+}
+
 static void
 cpu_enable_mpam(const struct arm64_cpu_capabilities *entry)
 {

arch/arm64/kernel/cpufeature.c static const struct arm64_cpu_capabilities arm64_features[] = { · line 3131

Quoted 9 lines

arch/arm64/kernel/cpufeature.c +6 -0

@@ -3116,6 +3123,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
              .matches = test_has_mpam,
              .cpu_enable = cpu_enable_mpam,
      },
+     {
+             .desc = "Memory Partitioning And Monitoring system registers",
+             .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+             .capability = ARM64_MPAM_SYSREGS,
+             .matches = test_has_mpam_sysregs,
+     },

We already have two system capabilities for MPAM so I'm not overly keen to add a third, especially as the MPAM code is largely confined to the resctrl driver. In fact, this feels a bit similar to things like TRBE and SPE in the sense that (a) we have to probe it per-cpu (b) it can be disabled by a higher EL and (c) most of the code is in a driver, but KVM needs to know how to switch it.

Neither TRBE nor SPE need entries in arm64_features[] at all, so something isn't right here...

Will

finalise_el2_state() clears the EL2 MPAM traps whenever the ID registers advertise MPAM, while KVM sets them only under ARM64_MPAM, which also requires MPAMEN. Without EL3 nothing sets that enable, so a guest reaches the MPAM registers while ID_AA64PFR0_EL1.MPAM reads 0 for it.

Gate the traps on the ID registers alone: MPAMEN isn't a term in any MPAM accessor, so they take effect without it. The cap tests the sanitised ID fields, which never exceed a CPU's own, so it's set only where finalise_el2_state already wrote MPAM2_EL2. MPAM3_EL3.TRAPLOWER is clear there, and arm64.nompam turns the cap off too.

Fixes 23b33d1e168c ("arm64: head.S: Initialise MPAM EL2 registers and disable traps")

Reviewed-by Yuan Yao <[email protected]>

Signed-off-by Fuad Tabba <[email protected]>

---

Notes:
Changes since v1:
- Commit message only. The code is unchanged, so Yuan Yao's Reviewed-by is carried.
- Fixes: names the commit that cleared the traps, rather than the one that added KVM's trapping.
- Says why the sanitised ID fields are the safe gate: the cap is set only where finalise_el2_state already wrote MPAM2_EL2.

Not covered, and answered on the v1 thread: a machine whose CPUs differ on MPAM, raised by Ben and by sashiko.

v1: https://lore.kernel.org/all/[email protected]/

 arch/arm64/include/asm/cpufeature.h     |  5 +++++
 arch/arm64/kernel/cpufeature.c          | 13 +++++++++++++
 arch/arm64/kvm/hyp/include/hyp/switch.h |  4 ++--
 arch/arm64/tools/cpucaps                |  1 +
 4 files changed, 21 insertions(+), 2 deletions(-)

arch/arm64/include/asm/cpufeature.h +0 -0

index 7404a6e83a930..8863ae99596bc 100644

Quoted 6 lines

arch/arm64/include/asm/cpufeature.h +0 -0

@@ -873,6 +873,11 @@ static __always_inline bool system_supports_mpam_hcr(void)
      return alternative_has_cap_unlikely(ARM64_MPAM_HCR);
 }
 

arch/arm64/include/asm/cpufeature.h static __always_inline bool system_supports_mpam_hcr(void) · line 880

Quoted 5 lines

arch/arm64/include/asm/cpufeature.h +5 -0

+static __always_inline bool system_supports_mpam_sysregs(void)
+{
+     return alternative_has_cap_unlikely(ARM64_MPAM_SYSREGS);
+}
+

What is the rationale for choosing alternative_has_cap_unlikely() instead of cpus_have_final_cap(), which is more wildly used?

        M.

--
Without deviation from the norm, progress is not possible.