* [PATCH] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available
@ 2023-01-28 0:14 Sean Christopherson
2023-01-31 7:20 ` Like Xu
2023-04-06 2:11 ` Sean Christopherson
0 siblings, 2 replies; 6+ messages in thread
From: Sean Christopherson @ 2023-01-28 0:14 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Yang Weijiang, Like Xu
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.
Cc: stable@vger.kernel.org
Cc: Yang Weijiang <weijiang.yang@intel.com>
Cc: Like Xu <like.xu.linux@gmail.com>
Reported-by: Paolo Bonzini <pbonzini@redhat.com>
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)) {
+ x86_perf_get_lbr(&lbr);
+ if (lbr.nr)
+ perf_cap |= host_perf_cap & PMU_CAP_LBR_FMT;
+ }
if (vmx_pebs_supported()) {
perf_cap |= host_perf_cap & PERF_CAP_PEBS_MASK;
base-commit: 2de154f541fc5b9f2aed3fe06e218130718ce320
--
2.39.1.456.gfc5497dd1b-goog
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available
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-04-06 2:11 ` Sean Christopherson
1 sibling, 1 reply; 6+ messages in thread
From: Like Xu @ 2023-01-31 7:20 UTC (permalink / raw)
To: Sean Christopherson; +Cc: kvm, linux-kernel, Yang Weijiang, Paolo Bonzini
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")
> 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;
?
> + x86_perf_get_lbr(&lbr);
> + if (lbr.nr)
> + perf_cap |= host_perf_cap & PMU_CAP_LBR_FMT;
> + }
>
> if (vmx_pebs_supported()) {
> perf_cap |= host_perf_cap & PERF_CAP_PEBS_MASK;
>
> base-commit: 2de154f541fc5b9f2aed3fe06e218130718ce320
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available
2023-01-31 7:20 ` Like Xu
@ 2023-02-02 19:11 ` Sean Christopherson
2023-02-03 5:59 ` Like Xu
0 siblings, 1 reply; 6+ messages in thread
From: Sean Christopherson @ 2023-02-02 19:11 UTC (permalink / raw)
To: Like Xu; +Cc: kvm, linux-kernel, Yang Weijiang, Paolo Bonzini
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).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available
2023-02-02 19:11 ` Sean Christopherson
@ 2023-02-03 5:59 ` Like Xu
2023-02-03 21:03 ` Sean Christopherson
0 siblings, 1 reply; 6+ messages in thread
From: Like Xu @ 2023-02-03 5:59 UTC (permalink / raw)
To: Sean Christopherson; +Cc: kvm, linux-kernel, Yang Weijiang, Paolo Bonzini
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. 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.
>
>>> 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).
Indeed, we have too many assumptions about the order of function calls in the
kernel world.
"Avoid ordering dependencies" looks good to me. Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available
2023-02-03 5:59 ` Like Xu
@ 2023-02-03 21:03 ` Sean Christopherson
0 siblings, 0 replies; 6+ messages in thread
From: Sean Christopherson @ 2023-02-03 21:03 UTC (permalink / raw)
To: Like Xu; +Cc: kvm, linux-kernel, Yang Weijiang, Paolo Bonzini
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!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available
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-04-06 2:11 ` Sean Christopherson
1 sibling, 0 replies; 6+ messages in thread
From: Sean Christopherson @ 2023-04-06 2:11 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Yang Weijiang, Like Xu
On Sat, 28 Jan 2023 00:14:27 +0000, 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.
>
>
Applied to kvm-x86 pmu, with a Fixes tag.
[1/1] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available
https://github.com/kvm-x86/linux/commit/098f4c061ea1
--
https://github.com/kvm-x86/linux/tree/next
https://github.com/kvm-x86/linux/tree/fixes
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-04-06 2:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2023-04-06 2:11 ` Sean Christopherson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).