Re: [PATCH 14/15] KVM: x86/pmu: Advertise PerfMon version 5 on Intel hosts

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

On 7/23/2026 4:53 PM, Jim Mattson wrote:
> On Tue, Jul 7, 2026 at 11:44 AM Zide Chen <zide.chen@intel.com> wrote:
>>
>> From: Dapeng Mi <dapeng1.mi@linux.intel.com>
>>
>> KVM currently caps the guest PerfMon version at 2 for all Intel
>> platforms. Now that KVM emulates the basic architectural PMU features
>> introduced in PerfMon versions 3 through 5, raise the guest PerfMon
>> version to 5.  Features that require additional emulation support, e.g.
>> architectural LBR will be enabled separately.
>>
>> When enable_mediated_pmu is disabled or in the non-Intel paths, KVM
>> retains the existing cap of version 2.
>>
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> Signed-off-by: Zide Chen <zide.chen@intel.com>
>> ---
>>  arch/x86/kvm/pmu.c | 13 ++++++++++++-
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>> index 7d58f7a2a2db..83332e8ed1e0 100644
>> --- a/arch/x86/kvm/pmu.c
>> +++ b/arch/x86/kvm/pmu.c
>> @@ -176,7 +176,18 @@ void kvm_init_pmu_capability(struct kvm_pmu_ops *pmu_ops)
>>         }
>>
>>         memcpy(&kvm_pmu_cap, &kvm_host_pmu, sizeof(kvm_host_pmu));
>> -       kvm_pmu_cap.version = min(kvm_pmu_cap.version, 2);
>> +
>> +       /*
>> +        * AnyThread counting is not supported by KVM due to cross-VM
>> +        * information leakage concerns on SMT cores. Therefore, AnyThread
>> +        * remains unavailable for PerfMon v3/v4 guests, where AnyThread
>> +        * deprecation is not enumerated.
>> +        */
>> +       if (is_intel && enable_mediated_pmu)
>> +               kvm_pmu_cap.version = min(kvm_pmu_cap.version, 5);
> 
> Our internal Sashiko says:
> 
> Does raising the version cap here expose guests with PMU versions 3 or 4 to
> a #GP-induced panic when they attempt to use the AnyThread feature?
> Since AnyThread is architecturally valid in PMU v3 and v4, a guest kernel
> detecting version 3 or 4 will enable AnyThread support. When the guest
> writes to MSR_P6_EVNTSELx with the AnyThread bit (bit 21) set, KVM
> intercepts it.
> Looking at arch/x86/kvm/vmx/pmu_intel.c:intel_pmu_refresh(), KVM includes
> the AnyThread bit in pmu->eventsel_rsvd, only clearing it for version >= 5:
>     if (pmu->version >= 5 && edx.split.anythread_deprecated)
>         pmu->eventsel_rsvd &= ~ARCH_PERFMON_EVENTSEL_ANY;
> Then, in intel_pmu_set_msr(), KVM injects a #GP because the eventsel_rsvd
> check triggers before any silent discard logic:
>     if (data & eventsel_rsvd)
>         return 1;
> Because the guest Linux kernel wrmsr path might lack exception handling for
> this MSR write, could this injected #GP cause an unhandled kernel exception
> and an immediate guest kernel panic?
> 

Currently KVM always injects #GP when the AnyThread bit is set.

kvm_pmu_refresh(): pmu->reserved_bits = 0xffffffff00200000ull;

I understand the concern, but I'm not aware of a better solution for
PMUv3/4. Silently ignoring AnyThread would deviate from the
architectural behavior and, more importantly, may give the guest the
false impression that AnyThread is supported. Supporting AnyThread, on
the other hand, has cross-VM information leakage concerns.

BTW, the comment seems a bit out of place here. It might fit better in
patch 13/15 which is specifically handling AnyThread .