[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2c804098-af2b-4f1d-a39f-eb42f58635d7@linux.intel.com>
Date: Tue, 7 Nov 2023 15:14:16 +0800
From: "Mi, Dapeng" <dapeng1.mi@...ux.intel.com>
To: Jim Mattson <jmattson@...gle.com>,
Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Kan Liang <kan.liang@...ux.intel.com>,
Jinrong Liang <cloudliang@...cent.com>,
Like Xu <likexu@...cent.com>,
Aaron Lewis <aaronlewis@...gle.com>
Subject: Re: [PATCH v6 03/20] KVM: x86/pmu: Don't enumerate arch events KVM
doesn't support
On 11/4/2023 8:41 PM, Jim Mattson wrote:
> On Fri, Nov 3, 2023 at 5:02 PM Sean Christopherson <seanjc@...gle.com> wrote:
>> Don't advertise support to userspace for architectural events that KVM
>> doesn't support, i.e. for "real" events that aren't listed in
>> intel_pmu_architectural_events. On current hardware, this effectively
>> means "don't advertise support for Top Down Slots".
> NR_REAL_INTEL_ARCH_EVENTS is only used in intel_hw_event_available().
> As discussed (https://lore.kernel.org/kvm/ZUU12-TUR_1cj47u@google.com/),
> intel_hw_event_available() should go away.
>
> Aside from mapping fixed counters to event selector and unit mask
> (fixed_pmc_events[]), KVM has no reason to know when a new
> architectural event is defined.
Since intel_hw_event_available() would be removed, it looks the enum
intel_pmu_architectural_events and intel_arch_events[] array become
useless. We can directly simply modify current fixed_pmc_events[] array
and use it to store fixed counter events code and umask.
>
> The variable that this change "fixes" is only used to feed
> CPUID.0AH:EBX in KVM_GET_SUPPORTED_CPUID, and kvm_pmu_cap.events_mask
> is already constructed from what host perf advertises support for.
>
>> Mask off the associated "unavailable" bits, as said bits for undefined
>> events are reserved to zero. Arguably the events _are_ defined, but from
>> a KVM perspective they might as well not exist, and there's absolutely no
>> reason to leave useless unavailable bits set.
>>
>> Fixes: a6c06ed1a60a ("KVM: Expose the architectural performance monitoring CPUID leaf")
>> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
>> ---
>> arch/x86/kvm/vmx/pmu_intel.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
>> index 3316fdea212a..8d545f84dc4a 100644
>> --- a/arch/x86/kvm/vmx/pmu_intel.c
>> +++ b/arch/x86/kvm/vmx/pmu_intel.c
>> @@ -73,6 +73,15 @@ static void intel_init_pmu_capability(void)
>> int i;
>>
>> /*
>> + * Do not enumerate support for architectural events that KVM doesn't
>> + * support. Clear unsupported events "unavailable" bit as well, as
>> + * architecturally such bits are reserved to zero.
>> + */
>> + kvm_pmu_cap.events_mask_len = min(kvm_pmu_cap.events_mask_len,
>> + NR_REAL_INTEL_ARCH_EVENTS);
>> + kvm_pmu_cap.events_mask &= GENMASK(kvm_pmu_cap.events_mask_len - 1, 0);
>> +
>> + /*
>> * Perf may (sadly) back a guest fixed counter with a general purpose
>> * counter, and so KVM must hide fixed counters whose associated
>> * architectural event are unsupported. On real hardware, this should
>> --
>> 2.42.0.869.gea05f2083d-goog
>>
Powered by blists - more mailing lists