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

On 2026/07/08 17:32, Akihiko Odaki wrote:
> 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.

I sent a new revision implementing these changes, but due to a rebase
mistake it was also sent as v8.

However, it still does not cover every case of non-uniform driver-backed
PMU availability. With ACPI, if a CPU is brought online whose MIDR was
not represented by any CPU online during PMU probing, the PMU code
cannot associate it with an existing arm_pmu or register a new one.
This can happen even when PMUVer is uniform across CPUs.

I therefore plan to take a simpler approach: when KVM cannot find a
registered pPMU for the vCPU's current CPU, emit a one-time warning and
set TAINT_CPU_OUT_OF_SPEC, matching the treatment of mismatched CPU
features.

Regards,
Akihiko Odaki

> 
> 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- 
> [email protected]?part=6
> 
> Regards,
> Akihiko Odaki
>