Re: [PATCH v3 6/8] KVM: x86/svm/pmu: Add AMD PerfMonV2 support

From: Sean Christopherson
Date: Mon Feb 06 2023 - 17:22:18 EST


On Mon, Feb 06, 2023, Like Xu wrote:
> On 25/1/2023 8:10 am, Sean Christopherson wrote:
> > > + }
> > > +
> > > + /* Commitment to minimal PMCs, regardless of CPUID.80000022 */
> >
> > Please expand this comment. I'm still not entirely sure I've interpreted it correctly,
> > and I'm not sure that I agree with the code.
>
> In the first version [1], I used almost the same if-elif-else sequence
> but the concerns from JimM[2] has changed my mind:
>
> "Nonetheless, for compatibility with old software, Fn8000_0022_EBX can never
> report less than four counters (or six, if Fn8000_0001_ECX[PerfCtrExtCore] is set)."
>
> Both in amd_pmu_refresh() and in __do_cpuid_func(), KVM implements
> this using the override approach of first applying the semantics of
> AMD_PMU_V2 and then implementing a minimum number of counters
> supported based on whether or not guest have PERFCTR_CORE,
> the proposed if-elif-else does not fulfill this need.

Jim's comments were in the context of __do_cpuid_func(), i.e. KVM_GET_SUPPORTED_CPUID.
As far as guest CPUID is concerned, that's userspace's responsibility to get correct.

And for KVM_GET_SUPPORTED_CPUID, overriding kvm_pmu_cap.num_counters_gp is not
the correct approach. KVM should sanity check the number of counters enumerated
by perf and explicitly disable vPMU support if the min isn't met. E.g. if KVM
needs 6 counters and perf says there are 4, then something is wrong and enumerating
6 to the guest is only going to cause more problems.

> [1] 20220905123946.95223-4-likexu@xxxxxxxxxxx/
> [2] CALMp9eQObuiJGV=YrAU9Fw+KoXfJtZMJ-KUs-qCOVd+R9zGBpw@xxxxxxxxxxxxxx