From: Like Xu <like.xu.linux@gmail.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v3 1/3] KVM: x86/pmu: Disable guest PEBS on hybird cpu due to heterogeneity
Date: Tue, 31 Jan 2023 16:53:51 +0800 [thread overview]
Message-ID: <617d9a3f-63a2-3ce2-b19a-2427ebbb7754@gmail.com> (raw)
In-Reply-To: <Y9gA9aZNxYAZGgPh@google.com>
On 31/1/2023 1:40 am, Sean Christopherson wrote:
> On Mon, Jan 30, 2023, Like Xu wrote:
>> On 20/1/2023 8:47 am, Sean Christopherson wrote:
>>> On Wed, Nov 09, 2022, Like Xu wrote:
>>>> From: Like Xu <likexu@tencent.com>
>>>>
>>>> From vPMU enabling perspective, KVM does not have proper support for
>>>> hybird x86 core. The reported perf_capabilities value (e.g. the format
>>>> of pebs record) depends on the type of cpu the kvm-intel module is init.
>>>> When a vcpu of one pebs format migrates to a vcpu of another pebs format,
>>>> the incorrect parsing of pebs records by guest can make profiling data
>>>> analysis extremely problematic.
>>>>
>>>> The safe way to fix this is to disable this part of the support until the
>>>> guest recognizes that it is running on the hybird cpu, which is appropriate
>>>> at the moment given that x86 hybrid architectures are not heavily touted
>>>> in the data center market.
>>>>
>>>> Signed-off-by: Like Xu <likexu@tencent.com>
>>>> ---
>>>> arch/x86/kvm/vmx/capabilities.h | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
>>>> index cd2ac9536c99..ea0498684048 100644
>>>> --- a/arch/x86/kvm/vmx/capabilities.h
>>>> +++ b/arch/x86/kvm/vmx/capabilities.h
>>>> @@ -392,7 +392,9 @@ static inline bool vmx_pt_mode_is_host_guest(void)
>>>> static inline bool vmx_pebs_supported(void)
>>>> {
>>>> - return boot_cpu_has(X86_FEATURE_PEBS) && kvm_pmu_cap.pebs_ept;
>>>> + return boot_cpu_has(X86_FEATURE_PEBS) &&
>>>> + !boot_cpu_has(X86_FEATURE_HYBRID_CPU) &&
>>>> + kvm_pmu_cap.pebs_ept;
>>>
>>> I assume the patch I just posted[*] to disable the vPMU entirely is sufficient, or
>>
>> AFAI, some developers doing client-side virtualization on a hybrid cpu will
>> specifically want vPMU,
>> in which case it makes perfect sense for KVM to expose common pmu
>> capabilities (not PEBS at the current) of big and little cores, such as the
>> most basic performance counter.
>>
>>> do we need this as well in order to hide X86_FEATURE_DS and X86_FEATURE_DTES64?
>>
>> I think we still need this diff. Better to prioritize this minor feature a
>> little bit for hungry users.
>
> That wasn't my question. My question was whether or not wholesale disabling vPMU
> is sufficient to prevent issues with PEBS. Unless we need this patch on top of
> disabling the vPMU, my strong preference is to disable vPMU, or at the very least
> make it off-by-default and require a explicit override.
OK and if so, just set global module parameter "enable_pmu=false" for HYBRID_CPU.
With "disable vPMU" diff, this patch should be dropped since
kvm_pmu_cap.pebs_ept = 0.
>
> I agree that there are users that want to enable vPMU for hybrid CPUs, but as
> stated in the link below, that needs to be a dedicated enabling effort. I don't
> see any reason to exempt PEBS from that. E.g. isn't PEBS usable if userspace pins
> vCPUs to pCPUs and enumerates an accurate topology to the guest?
So for HYBRID_CPU, {pebs, lbr, basic PMU} would be disabled globally by KVM
until a dedicated effort enables them one by one in the near future.
Follow up with a rewritten diff, 20230131085031.88939-1-likexu@tencent.com
>
>>> [*] https://lore.kernel.org/all/20230120004051.2043777-1-seanjc@google.com
next prev parent reply other threads:[~2023-01-31 8:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 8:27 [PATCH v3 0/3] KVM: x86/pmu: Enable guest PEBS for SPR and later models Like Xu
2022-11-09 8:28 ` [PATCH v3 1/3] KVM: x86/pmu: Disable guest PEBS on hybird cpu due to heterogeneity Like Xu
2022-11-25 10:18 ` Kunkun Jiang
2022-11-25 10:59 ` Like Xu
2023-01-20 0:47 ` Sean Christopherson
2023-01-30 11:30 ` Like Xu
2023-01-30 17:40 ` Sean Christopherson
2023-01-31 8:53 ` Like Xu [this message]
2022-11-09 8:28 ` [PATCH v3 2/3] KVM: x86/pmu: Add PRIR++ and PDist support for SPR and later models Like Xu
2022-11-09 8:28 ` [PATCH v3 3/3] perf/x86/intel: Expose EPT-friendly PEBS for SPR and future models Like Xu
2022-11-14 12:46 ` Peter Zijlstra
2022-11-15 7:16 ` Like Xu
2023-02-02 1:32 ` [PATCH v3 0/3] KVM: x86/pmu: Enable guest PEBS for SPR and later models Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=617d9a3f-63a2-3ce2-b19a-2427ebbb7754@gmail.com \
--to=like.xu.linux@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome