On 2026/07/07 2:04, Oliver Upton wrote:
Hi,
On Mon, Jul 06, 2026 at 07:03:24PM +0900, Akihiko Odaki wrote:
Commit ec3eb9ed6081 ("KVM: arm64: PMU: Disallow vPMU on non-uniform
PMUVer") made KVM reject vPMU unless the system-wide PMUVer is usable.
That covers systems where PMUv3 is absent or non-uniform, as well as
systems where IMPDEF PMUv3 sysreg traps are unavailable.
However, KVM can still accept vPMU when all CPUs uniformly trap PMUv3
sysregs, but the pPMUs registered with KVM only cover a subset of
possible CPUs.
Reject vPMU unless the registered pPMUs cover every possible CPU.
This avoids carrying support for partial pPMU coverage into the
fixed-counters-only UAPI introduced later in the series.
Doesn't CPU hotplug screw this up? I could online a CPU that doesn't
have a PMU after creating the VM.>
I'd rather just change ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS to become a
system feature. That way any CPU which breaks the system-wide assumption
cannot be onlined.
ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS only says that IMPDEF PMUv3 sysregs
are trapped. It does not say that KVM has a driver-backed PMU usable for
PMUv3 emulation. This patch checks that extra requirement.
I re-checked CPU hotplug. Onlining a CPU without a PMU later does not
make an accepted VM unsafe, since the check is against
cpu_possible_mask. The problem is the reverse case on ACPI: this check
can disable vPMU when a possible CPU is offline. DT populates
supported_cpus at boot, while ACPI initially populates it only from
online CPUs and grows it as matching CPUs come online.
That makes this patch too conservative. In practice, I do not expect
systems to mix CPUs with and without a usable PMU. A better approach is
probably to treat such a host as out of spec and add
TAINT_CPU_OUT_OF_SPEC. We already do that for architectural PMUv3 by
detecting mismatches in ID_AA64DFR0_EL1.PMUVer; we can do the same for
ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS with non-standard PMUs.
Regards,
Akihiko Odaki
