On 2026/07/08 3:20, Oliver Upton wrote:
On Tue, Jul 07, 2026 at 08:08:03PM +0900, Akihiko Odaki wrote:
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.
Sorry, I missed that this was against the 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.
The presence of the workaround is, by definition, out of spec. I just
never bothered tainting the kernel because these machines are already
TAINT_CPU_OUT_OF_SPEC by way of the broken VGIC.
Ok, so how about you keep the check that you're doing here and promote
IMPDEF_TRAPS to a system-wide feature? That would satisfy the two
preconditions we have for PMU emulation, which is system register traps
and a backing arm_pmu that understands PMUv3 events.
This check turned out to be faulty: it can disable PMU emulation on ACPI
systems when a possible CPU is offline, because ACPI grows
arm_pmu::supported_cpus as matching CPUs come online.
My current plan is:
- drop the possible-mask coverage check, to avoid breaking ACPI;
- promote ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS to
ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE, so the system will have the
feature only if all online CPUs implement it;
- explicitly taint hosts with ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS,
matching what KVM already does for non-architectural VGICs. The
comment will make it clear that this is out of spec because KVM cannot
make the usual architectural assumptions about PMUv3 sysreg traps and
uniform driver-backed PMU availability.
That lets the code keep assuming uniform PMU availability without adding
an ACPI-hostile possible-CPU check, and makes that assumption explicit
for humans like me and tools such as Sashiko [1].
[1]
https://sashiko.dev/#/patchset/[email protected]?part=6
Regards,
Akihiko Odaki
