Starting with v5, the Intel PMU allows to indicate the available fixed
function PMCs not only through CPUID.0AH.EDX[4:0] but also through a
bit mask in CPUID.0AH.ECX. According to the SDM the OS can consider a
fix function PMC i supported for:

CPUID.0AH.ECX[i] || (CPUID.0AH.EDX[4:0] > i)

This behavior is already supported by the Intel PMU driver. However, KVM
support is missing. This patch series add the support by first
refactoring the tracking of available fixed function PMCs in KVM from a
number to a bitmap in the frist patch. The second patch populates the
bitmap accoring to the rule given by the SDM mentioned above.

Regards,
Anselm

Anselm Busse (2):
  KVM: vmx/pmu: Indicate available fixed function PMCs through a bitmap
  KVM: vmx/pmu: Add support for selected fixed vPMU enablement for PMU v5

 arch/x86/include/asm/kvm_host.h |  2 +-
 arch/x86/kvm/pmu.h              |  6 ++---
 arch/x86/kvm/svm/pmu.c          |  2 +-
 arch/x86/kvm/vmx/pmu_intel.c    | 40 ++++++++++++++++++++-------------
 4 files changed, 30 insertions(+), 20 deletions(-)


base-commit: 0cfd8703e7da687924371e9bc77a025bdeba9637
-- 
2.39.2




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

On 27/4/2023 5:53 pm, Anselm Busse wrote:
> Starting with v5, the Intel PMU allows to indicate the available fixed
> function PMCs not only through CPUID.0AH.EDX[4:0] but also through a
> bit mask in CPUID.0AH.ECX. According to the SDM the OS can consider a
> fix function PMC i supported for:
> 
> CPUID.0AH.ECX[i] || (CPUID.0AH.EDX[4:0] > i)

Yes, this feature is attractive for virtualization scenarios, and it gives 
flexibility
to control which fixed counters are available or not in the virtual machine.

However, currently KVM/x86 also supports Intel PMU V2, so I would expect
that we will review the enablement code for v3 and v4 first.

Ref: 
https://lore.kernel.org/kvm/CALMp9eQVnk8gkOpX5AHhaCr8-5Fe=qNuX8PUP1Gv2H5FSYmHSw@mail.gmail.com/

> 
> This behavior is already supported by the Intel PMU driver. However, KVM
> support is missing. This patch series add the support by first
> refactoring the tracking of available fixed function PMCs in KVM from a
> number to a bitmap in the frist patch. The second patch populates the
> bitmap accoring to the rule given by the SDM mentioned above.
> 
> Regards,
> Anselm
> 
> Anselm Busse (2):
>    KVM: vmx/pmu: Indicate available fixed function PMCs through a bitmap
>    KVM: vmx/pmu: Add support for selected fixed vPMU enablement for PMU v5
> 
>   arch/x86/include/asm/kvm_host.h |  2 +-
>   arch/x86/kvm/pmu.h              |  6 ++---
>   arch/x86/kvm/svm/pmu.c          |  2 +-
>   arch/x86/kvm/vmx/pmu_intel.c    | 40 ++++++++++++++++++++-------------
>   4 files changed, 30 insertions(+), 20 deletions(-)
> 
> 
> base-commit: 0cfd8703e7da687924371e9bc77a025bdeba9637

On Tue, May 16, 2023, Like Xu wrote:
> On 27/4/2023 5:53 pm, Anselm Busse wrote:
> > Starting with v5, the Intel PMU allows to indicate the available fixed
> > function PMCs not only through CPUID.0AH.EDX[4:0] but also through a
> > bit mask in CPUID.0AH.ECX. According to the SDM the OS can consider a
> > fix function PMC i supported for:
> > 
> > CPUID.0AH.ECX[i] || (CPUID.0AH.EDX[4:0] > i)
> 
> Yes, this feature is attractive for virtualization scenarios, and it gives
> flexibility to control which fixed counters are available or not in the
> virtual machine.
> 
> However, currently KVM/x86 also supports Intel PMU V2, so I would expect
> that we will review the enablement code for v3 and v4 first.

Looking at v3, I think we probably want to skip straight to v5.  I don't see a sane
way for KVM to emulate/virtualize AnyThread, which comes in v3 without a separate
CPUID feature flag.  The SDM even calls out that it'd be a mess to deal with in a
virtualized environment.  v5 introduces a CPUID bit to allow deprecating AnyThread,
i.e. would give KVM the ability to advertise a sane vPMU model to userspace.
Amusingly, KVM advertises "edx.split.anythread_deprecated = 1" for v1+, so maybe
we don't even need to do any enabling?  At glance, I don't see any other changes
in v3 that require KVM support.

v4 looks to be an entirely different story than v3 though.  So I agree with Like
that we need to enable v3 and v4 before advertising support for v5.  And KVM *does*
need to actually advertise v5.  Emulating the fixed counter bitmap without a way to
tell userspace about the functionality will create a mess.

TL;DR: If y'all want the shiny features in v5, please enable v3 and v4 first.  I'm
totally fine taking a series to go all the way to v5 (might even be preferred due
to the AnyThread crud), but I don't want to advertise v5 without supporting the
required v3/v4 features.

> Ref: https://lore.kernel.org/kvm/CALMp9eQVnk8gkOpX5AHhaCr8-5Fe=qNuX8PUP1Gv2H5FSYmHSw@mail.gmail.com/

I agree 100% with Jim, the bitmask stuff is firmly v5+.