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

[Sean Christopherson]

On Wed, Nov 11, 2026, Zide Chen wrote:
> On 11/11/2026 9:37 AM, Sean Christopherson wrote:
> > 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.

...

> > Just because we *can* do something in KVM doesn't mean we *should* do that thing
> > in KVM.    
> 
> Got it.
> 
> >>>> - 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...
> 
> Got it. I can think of a few discrepancies:
> 
> For example, the guest is supposed to handle Freeze_LBRs_On_PMI (legacy
> vs. streamlined) based on the guest PMU version. If KVM emulates the
> legacy behavior, but a v4+ guest expects the streamlined one, it may
> run into issues.

Well, yeah.  Because I'm saying KVM should *NOT* support running guests with a
"greater" vPMU version than is present in underlying hardware.  That's nothing
new; KVM rarely emulates features that don't exist in underlying hardare.

KVM doesn't generally enforce the virtual CPU model presented to the guest though,
because (a) userspace can do all of the same checks KVM can, e.g. by validating
its configuration against KVM_GET_SUPPORTED_CPUID, (b) adding that validation
in KVM would require a ton of code and create all kinds of ABI issues, and (c)
there are legitimate use cases for exposing a virtual CPU model that appears to
be insane/nonsensical.