All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Like Xu <like.xu.linux@gmail.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yang Weijiang <weijiang.yang@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available
Date: Thu, 2 Feb 2023 19:11:56 +0000	[thread overview]
Message-ID: <Y9wK/LkBYusOv1DO@google.com> (raw)
In-Reply-To: <f106a06e-ae6f-2c79-df87-721817aacc02@gmail.com>

On Tue, Jan 31, 2023, Like Xu wrote:
> On 28/1/2023 8:14 am, Sean Christopherson wrote:
> > Disallow enabling LBR support if the CPU supports architectural LBRs.
> > Traditional LBR support is absent on CPU models that have architectural
> > LBRs, and KVM doesn't yet support arch LBRs, i.e. KVM will pass through
> > non-existent MSRs if userspace enables LBRs for the guest.
> 
> True, we have call_trace due to MSR_ARCH_LBR_FROM_0 (0x1500) for example.
> 
> > 
> > Cc: stable@vger.kernel.org
> > Cc: Yang Weijiang <weijiang.yang@intel.com>
> > Cc: Like Xu <like.xu.linux@gmail.com>
> 
> Tested-by: Like Xu <likexu@tencent.com>
> 
> > Reported-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> Fixes: 145dfad998ea ("KVM: VMX: Advertise PMU LBRs if and only if perf
> supports LBRs")

If we want a fixes, I'd argue this is more appropriate:

  Fixes: be635e34c284 ("KVM: vmx/pmu: Expose LBR_FMT in the MSR_IA32_PERF_CAPABILITIES")

Though I'd prefer not to blame KVM, there's not much we could have done in KVM
to know that Intel would effectively break backwards compatibility.

> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> > 
> > Am I missing something that would prevent this scenario?
> > 
> >   arch/x86/kvm/vmx/vmx.c | 8 +++++---
> >   1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index 8f0f67c75f35..77ee6b4a5ec4 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -7761,9 +7761,11 @@ static u64 vmx_get_perf_capabilities(void)
> >   	if (boot_cpu_has(X86_FEATURE_PDCM))
> >   		rdmsrl(MSR_IA32_PERF_CAPABILITIES, host_perf_cap);
> > -	x86_perf_get_lbr(&lbr);
> > -	if (lbr.nr)
> > -		perf_cap |= host_perf_cap & PMU_CAP_LBR_FMT;
> > +	if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR)) {
> 
> To avoid changing this again in the Arch lbr enabling part, how about:
> 
> 	x86_perf_get_lbr(&lbr);
> 	if (lbr.nr && cpu_feature_enabled(X86_FEATURE_ARCH_LBR) ==
> 	    kvm_cpu_cap_has(X86_FEATURE_ARCH_LBR))
> 		perf_cap |= host_perf_cap & PMU_CAP_LBR_FMT;
> 
> ?

I'd rather force arch LBR enabling to explicitly update this code.  And I'd prefer
that KVM explicitly clear PMU_CAP_LBR_FMT when KVM can't use arch LBRs for whatever
reason, both for documentation purposes and to avoid ordering dependencies between
consuming vmx_get_perf_capabilities() and updating kvm_cpu_cap_has(X86_FEATURE_ARCH_LBR).

  reply	other threads:[~2023-02-02 19:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-28  0:14 [PATCH] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available Sean Christopherson
2023-01-31  7:20 ` Like Xu
2023-02-02 19:11   ` Sean Christopherson [this message]
2023-02-03  5:59     ` Like Xu
2023-02-03 21:03       ` Sean Christopherson
2023-04-06  2:11 ` 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=Y9wK/LkBYusOv1DO@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=like.xu.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=weijiang.yang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.