Message ID | 20230128001427.2548858-1-seanjc@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1113524wrn; Fri, 27 Jan 2023 16:17:29 -0800 (PST) X-Google-Smtp-Source: AMrXdXtCOe0JWoH+b0xPOFr0hXLeTi1Ips5igdnt26IwmSr/Iuu3eE+nEoDpw5BI0AQTQYNLFH+0 X-Received: by 2002:a05:6a20:d394:b0:b8:9922:dd2a with SMTP id iq20-20020a056a20d39400b000b89922dd2amr45547953pzb.57.1674865048842; Fri, 27 Jan 2023 16:17:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674865048; cv=none; d=google.com; s=arc-20160816; b=yqqT0SMKkIrulRVcqq4iSq1mWkSnxDgZ3DyJ8POEYU0rP1KqHCcDaar5laY0/WXXrC f92t8yMw188TajHtjsXrBr5XnuyYInBoEbh1CyvryEgV8Qpg8miQ5H8DAac8/vfEH2U1 LhLpxB5z+0fHdPABQ9Jx5hGgVTIgQ+2J8Q+4p9pLXImSU4PAzDkifQJBeb2nmxkEsFBT Mx7j1+UBt6FLowsUWXUOGo0CzBFL35rVWLg/AcXqxbG8qKqDWmDUyQv/ZRQ5U/SIeoCj 7OJT0J4uilUo1QSJOmT5m3rYT/WAeyTSiy/4S0QegfccQNl6kEdRIC1ulU0jwdLKfD1I Ce5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :reply-to:dkim-signature; bh=iwlcdlJJgNxaN7KocVWCGFnG+kPyVohvYqXCxDe6XuM=; b=WSVsiOC4C4DFosTTWsIVheDmDHNP1pgDVt5aha2jUFOHOjOwP/ue1xmXIG3y3RgAxp HybqpyIW81Nmj6DQ6tXxO7kLlv3q3PFTjsKonN/sCwE+uTewEfyJDXmvQ2phfJIHCCIK KSqOBfAowlUqQBkF50ahivrHL3Arpdg1m91ZrFIwqjyTaYRMqKx15p4QkXbOu9cjNJzG UQspYSS+L1gq4X7a7RyW7eZccFaL4ICUml4XjvYyj/O0P7Rnqsm2MHk+5G+jy1viC9ku 9RO14k/jhlLeTHAWt0UFKXqmQ0+UBy/KRzKk/JQk5qpxYwExljESQSluIA0P2yuAnGWi D9IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="mAL/PvUS"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v25-20020a637a19000000b004cbb361aaf3si1350646pgc.39.2023.01.27.16.17.14; Fri, 27 Jan 2023 16:17:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="mAL/PvUS"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231651AbjA1AOc (ORCPT <rfc822;jesperjuhl76@gmail.com> + 99 others); Fri, 27 Jan 2023 19:14:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229464AbjA1AOb (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 27 Jan 2023 19:14:31 -0500 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 762717B415 for <linux-kernel@vger.kernel.org>; Fri, 27 Jan 2023 16:14:30 -0800 (PST) Received: by mail-pg1-x54a.google.com with SMTP id s76-20020a632c4f000000b0049ceb0f185eso2770791pgs.7 for <linux-kernel@vger.kernel.org>; Fri, 27 Jan 2023 16:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc :subject:date:message-id:reply-to; bh=iwlcdlJJgNxaN7KocVWCGFnG+kPyVohvYqXCxDe6XuM=; b=mAL/PvUSfxHJU7ATYhzNLnuzW9F2kvWTQEwpOIpDfhAtTqnD/Pf4LqrF1myJH6GbBy eusgGt0Ee3nfpYFyW192VjAIVORMH3fs8qyByuFvzuNOfXnEtSib4PPJwhx+HZG97I7H cDZWggsyLo6Mo7kYzLT9W3/nWwppkUzs+TJGyCD/codVSyeZSKidETC/2gT97QYHj8sp MFLgn+miHvKc/XlYJjx9jLWR5TZ0WN9HitIfRptRCn7bTSi5yQ04SZObOBn+/S4Jp0BX ZJ0Q/36NLzBcIwmcaR0fdKg4//N6w+zVi8xeasf0322d03ieBSz74NTJoD+rbuCFZhTq /gjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:reply-to :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iwlcdlJJgNxaN7KocVWCGFnG+kPyVohvYqXCxDe6XuM=; b=KuqUYS/jHCu1jyb17EGAZmJ6G0xGkc7tvNHr4Q6JSEVsIuGccW2p2WZzwkvFvCmWme URLHn3gvzl9juX+bxfQF89yRl4IMZsTesrP+hCeALlQGYePFBOe5zaktF1fTIZXxP1T8 n+RI/hNX/ZRX+Z0BS1kOOqvs3bPi1iYkeLtMAWveiG7EnKOQ3tMlLouiiKDfAAbIcQ+5 6cpnUWGR7QQQfhyHwfnukMfoSDbzMo6XUCe/S2Bu68E0QgQ7Lv8AmFYmyYucvxKzlDmf 2DBEmhRJJMPpaoG6NF1D73sQ+D/VUTkuk9Sbqtqm4UkzNdosR6RXRyHgWJO2YjSFnei2 OsQw== X-Gm-Message-State: AO0yUKXIvBXAqmzhDpaOavRchHZijRCtHZo2ATpK2tP7oOdo8JQxtOgs Uuu86BOsseHUz0sK5QFFZkwh64/OoXw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:1990:b0:593:909f:ed45 with SMTP id d16-20020a056a00199000b00593909fed45mr181136pfl.0.1674864869971; Fri, 27 Jan 2023 16:14:29 -0800 (PST) Reply-To: Sean Christopherson <seanjc@google.com> Date: Sat, 28 Jan 2023 00:14:27 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.1.456.gfc5497dd1b-goog Message-ID: <20230128001427.2548858-1-seanjc@google.com> Subject: [PATCH] KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available From: Sean Christopherson <seanjc@google.com> To: Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Yang Weijiang <weijiang.yang@intel.com>, Like Xu <like.xu.linux@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756223293520547746?= X-GMAIL-MSGID: =?utf-8?q?1756223293520547746?= |
Series |
KVM: x86/pmu: Disallow legacy LBRs if architectural LBRs are available
|
|
Commit Message
Sean Christopherson
Jan. 28, 2023, 12:14 a.m. UTC
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(-)
base-commit: 2de154f541fc5b9f2aed3fe06e218130718ce320
Comments
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
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).
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.
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!
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
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;