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: Fri, 3 Feb 2023 21:03:31 +0000 [thread overview]
Message-ID: <Y912o2iB96G8K1PP@google.com> (raw)
In-Reply-To: <79bab707-6592-0c45-d21f-c3014362bb82@gmail.com>
On Fri, Feb 03, 2023, Like Xu wrote:
> On 3/2/2023 3:11 am, Sean Christopherson wrote:
> > 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.
>
> Personally, I assume the bigger role of the Fix tag is to help the stable tree's
> bots make it easier to back port patches automatically, and there will be less
> sense of blame for the developers.
I don't mind adding a Fixes to aid stable, but then
Fixes: be635e34c284 ("KVM: vmx/pmu: Expose LBR_FMT in the MSR_IA32_PERF_CAPABILITIES")
is still more correct, e.g. if there are kernel's that didn't get
145dfad998ea ("KVM: VMX: Advertise PMU LBRs if and only if perf supports LBRs")
for whatever reason.
> In pmu scope, if a feature is not "architecture", I'm not surprised that a
> new arrival will break compatibility, and sometimes kernel developers need to
> plan ahead.
Hrm, true, compatibility is usually a non-goal for uarch stuff. I'll try to keep
that in mind for future vPMU code.
Thanks!
next prev parent reply other threads:[~2023-02-03 21:06 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
2023-02-03 5:59 ` Like Xu
2023-02-03 21:03 ` Sean Christopherson [this message]
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=Y912o2iB96G8K1PP@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox