Re: [PATCH] KVM: arm64: Trap guest MPAM accesses whenever MPAM is implemented
From: Yao Yuan <hidden>
Date: 2026-09-04 23:07:32
Also in:
kvmarm, lkml
On Fri, Sep 04, 2026 at 12:18:00PM +0800, Fuad Tabba wrote:
Hi Yuan,quoted
quoted
+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(); +}My understanding: arm64.nompam affects detect_ftr_has_mpam(), thus when arm64.nompam = 1 w/ MPAM is supported in hardware, the KVM's trap setting is skipped yet, and it's possible that SYS_MPAM2_EL2 and SYS_MPAMHCR_EL2 are configured not trap anything by firmware, thus guest can still access MPAM registers. Do we need check the raw id register values for the real support state of MPAM here ?Under arm64.nompam, finalise_el2_state skips the MPAM2_EL2 and MPAMHCR_EL2 writes too, via the same check_override, so the kernel does not clear the traps either. What a guest reaches there is whatever EL3 left, UNKNOWN when EL3 is implemented.
That's what I was worried before w/ nompam = 1 for guest can still access the MPAM registers. Now it's fine to me w/ limitation on usage of nompam described in [1], the limitation on guest behavior described there yet. Thanks for the reply! I just not aware [1] before.
This patch is for the case where the kernel cleared the traps itself and never set them again.
Yes next time I will explicitly say want to discuss something may related to the patch's main purpose.
Gating on the raw ID registers would make __activate_traps_mpam()
write MPAM2_EL2 on guest entry there. AFAICT that traps to EL3
wherever MPAM3_EL3.TRAPLOWER is still set, which is the firmware the
option is for: 10f885d63a0e ("arm64: Add override for MPAM") added it
for firmware that leaves the trap set and does not emulate it.Make sense, it break the nompam actually on platform need it, this isn't good idea. For the purpose of this patch: Reviewed-by: Yuan Yao <redacted>
The arm64.nompam hazard is documented separately [1]. Cheers, /fuad [1] https://lore.kernel.org/all/20260903084809.2027326-1-fuad.tabba@linux.dev/ (local)