Re: [PATCH v3 13/18] KVM: x86/pmu: Populate CPUID.0AH:ECX fixed-counter bitmap

[Sean Christopherson <seanjc@google.com>]

On Tue, Nov 10, 2026, Zide Chen wrote:
> >>> KVM's principle of "not policing guest CPUID" means KVM allows userspace
> >>> to configure an arbitrary guest CPUID without rejecting the ioctl or
> >>> mutating the vCPUID entries.
> >>>
> >>> However, KVM's internal vCPU state (pmu->version) tracks the "effective
> >>> PMU version" that KVM can actually virtualize.
> >>>
> >>> This distinction is documented in commit 4f1bd6b16074 ("KVM: selftests:
> >>> Test Intel PMU architectural events on gp counters"):
> >>>
> >>> "KVM only officially supports up to version 2, but the behavior of the
> >>> counters is backwards compatible, i.e. KVM shouldn't do something
> >>> completely different for a higher, architecturally-defined vPMU version.
> >>> Verify KVM behavior against the effective vPMU version, e.g. dvertising
> >>> vPMU 5 when KVM only supports vPMU 2 shouldn't magically unlock vPMU 5
> >>> features."
> >>>
> >>> pmu_counters_test itself explicitly mentions this rule:
> >>>
> >>> /*
> >>>  * Return the effective PMU version, i.e. the minimum between what KVM
> >>>  * supports and what is enumerated to the guest.  The host deliberately
> >>>  * advertises a PMU version to the guest beyond what is actually
> >>>  * supported by KVM to verify KVM doesn't freak out and do something
> >>>  * bizarre with an architecturally valid, but unsupported, version.
> >>>  */

...

> >>> Without a PMU version cap, guest resource validation could become
> >>> increasingly complicated as more advanced PMU features are supported, as
> >>> KVM would need to allow the guest to access PMU resources only when it
> >>> satisfies both the vPMU version and the KVM capability.
> >> The above sounds reasonable at first glance, but in practice it is
> >> problematic because it arbitrarily masks out features that can be 100%
> >> emulated in software even when there is zero host hardware dependency:
> >>
> >> - Features that can be emulated entirely in software (e.g. there is no
> >> problem emulating the PerfMon v5 AnyThread deprecation, or emulating
> >> MSRs like GLOBAL_STATUS_SET or GLOBAL_INUSE on a v2/v3 host). Clamping
> >> the version unnecessarily prevents the guest from using features that
> >> correspond to its configured PMU version.

Just because we *can* do something in KVM doesn't mean we *should* do that thing
in KVM.    

> >> - Features that actually need host hardware support need to be checked
> >> against both guest and host PMU capabilities.
> >>
> >> I'd propose something like this instead, leaving pmu->version unclamped:

Why?  What real world use case is there for KVM actively supporting a PMU version
"greater" than the underlying hardware?  E.g. emulating AnyThread deprecation is
(presumably) easy, emulating *all* of v5 on a v3 host, not so much...