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

[Oliver Upton <oupton@kernel.org>]

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.

Thanks,
Oliver