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

["Chen, Zide" <zide.chen@intel.com>]

On 11/12/2026 11:09 AM, Sean Christopherson wrote:
> 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.

Thanks! That makes complete sense. I'll drop kvm_pmu_has_version() and
clamp pmu->version to kvm_pmu_cap.version in v4.