[PATCH v8 1/7] KVM: arm64: Disallow vPMU when pPMUs do not cover all CPUs

[Akihiko Odaki]

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/20260706-hybrid-v8-0-de459617b59d@rsg.ci.i.u-tokyo.ac.jp?part=6

Regards,
Akihiko Odaki