From: "Chen, Zide" <zide.chen@intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
kvm@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
Stephane Eranian <eranian@google.com>,
linux-kernel@vger.kernel.org, Mingwei Zhang <mizhang@google.com>,
Das Sandipan <Sandipan.Das@amd.com>,
Shukla Manali <Manali.Shukla@amd.com>,
Dapeng Mi <dapeng1.mi@linux.intel.com>,
Xudong Hao <xudong.hao@intel.com>
Subject: Re: [PATCH v9 11/12] KVM: x86/pmu: Reject writes to reserved MSR_PERF_METRICS bits
Date: Tue, 27 Oct 2026 17:09:43 -0500 [thread overview]
Message-ID: <6da36d01-c456-4bd9-8d3a-591e98ab3481@intel.com> (raw)
In-Reply-To: <20261023184505.3284911-1-jmattson@google.com>
On 10/23/2026 1:45 PM, Jim Mattson wrote:
> On Fri, Sep 18, 2026 at 12:39 PM Zide Chen <zide.chen@intel.com> wrote:
>>
>> + if (kvm_pmu_cap.num_topdown_events < INTEL_TD_METRIC_NUM)
>> + pmu->perf_metrics_rsvd =
>> + ~(BIT_ULL(kvm_pmu_cap.num_topdown_events *
>> + INTEL_TD_METRIC_FIELD_BITS) - 1);
>> + else
>> + pmu->perf_metrics_rsvd = 0;
>
> perf only sets x86_pmu.num_topdown_events for the models it knows about
> (Ice Lake and intel_pmu_init_glc() users). On a non-hybrid part that
> perf treats as "generic_arch_v5+", PERF_CAPABILITIES.PERF_METRICS_AVAILABLE
> can be set while num_topdown_events is 0. (intel_pmu_init() even sets
> GLOBAL_CTRL_EN_PERF_METRICS in intel_ctrl in that case.)
>
> vmx_get_perf_capabilities() will still advertise PERF_CAP_PERF_METRICS,
> but perf_metrics_rsvd will be ~0ull. The guest writes PERF_METRICS
> directly, and the hardware updates it on its own, so KVM_GET_MSRS can
> return a non-zero value that KVM_SET_MSRS will then reject. That breaks
> save/restore. (The selftest's write of 0xdeaddead would also fail.)
>
> Shouldn't vmx_get_perf_capabilities() withhold PERF_CAP_PERF_METRICS
> (and PERF_CAP_RDPMC_METRICS_CLEAR) when kvm_pmu_cap.num_topdown_events
> is 0?
Yes, this is safer. Will updated vmx_get_perf_capabilities() to gate
advertising both PERF_CAP_PERF_METRICS and PERF_CAP_RDPMC_METRICS_CLEAR
on num_topdown_events.
> The SDM, volume 3, section 22.8, says:
>> IA32_PERF_CAPABILITIES.PERF_METRICS_AVAILABLE[15]: If set, indicates
>> that the architecture provides built in support for [four] TMA L1
>> metrics through the PERF_METRICS MSR.
>
> So, four could be a fallback, but if the part actually implements
> eight, the upper fields would break the round trip in the same way.
>
> Also, since the guest's own writes go straight to hardware, this check
> really exists to keep the wrmsrq() in intel_mediated_pmu_load() from
> faulting on a bogus userspace value. The commit message should say so.
Agreed. I will update the commit message to clarify that because guest
writes are passed through to hardware, the primary purpose of this check
in intel_pmu_set_msr() is to prevent userspace (e.g. via KVM_SET_MSRS)
from stuffing invalid metric values that would cause the unchecked
wrmsrq() in intel_mediated_pmu_load() to #GP on VM-entry.
next prev parent reply other threads:[~2026-10-27 22:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 19:39 [PATCH v9 00/12] KVM: x86/pmu: Add hardware Topdown metrics support Zide Chen
2026-09-18 19:39 ` [PATCH v9 01/12] KVM: x86/pmu: Do not map fixed counters >= 3 to generic perf events Zide Chen
2026-09-18 19:39 ` [PATCH v9 02/12] KVM: x86/pmu: Support Intel fixed counter 3 on mediated vPMU Zide Chen
2026-09-18 19:39 ` [PATCH v9 03/12] KVM: x86/pmu: Rename and move vcpu_get_perf_capabilities() to pmu.h Zide Chen
2026-09-18 19:39 ` [PATCH v9 04/12] KVM: x86/pmu: Snapshot host IA32_PERF_CAPABILITIES in kvm_host Zide Chen
2026-09-18 19:39 ` [PATCH v9 05/12] KVM: x86/pmu: Support PERF_METRICS MSR in mediated vPMU Zide Chen
2026-10-23 18:27 ` Jim Mattson
2026-10-27 21:30 ` Chen, Zide
2026-09-18 19:39 ` [PATCH v9 06/12] KVM: x86/pmu: Move RDPMC emulation into per-vendor callbacks Zide Chen
2026-09-18 19:39 ` [PATCH v9 07/12] KVM: x86/pmu: Emulate RDPMC on performance metrics Zide Chen
2026-10-23 18:33 ` Jim Mattson
2026-09-18 19:39 ` [PATCH v9 08/12] KVM: selftests: Add PERF_METRICS and fixed counter 3 tests Zide Chen
2026-09-18 20:08 ` sashiko-bot
2026-09-18 20:45 ` Chen, Zide
2026-09-18 19:39 ` [PATCH v9 09/12] perf/x86: Add INTEL_TD_METRIC_FIELD_{BITS,MASK} constants Zide Chen
2026-09-18 19:59 ` sashiko-bot
2026-09-18 20:45 ` Chen, Zide
2026-09-21 7:01 ` Mi, Dapeng
2026-10-27 21:39 ` Chen, Zide
2026-09-18 19:39 ` [PATCH v9 10/12] perf/x86: Expose number of Topdown metric events to KVM Zide Chen
2026-09-21 7:06 ` Mi, Dapeng
2026-09-18 19:39 ` [PATCH v9 11/12] KVM: x86/pmu: Reject writes to reserved MSR_PERF_METRICS bits Zide Chen
2026-09-21 7:11 ` Mi, Dapeng
2026-10-23 18:45 ` Jim Mattson
2026-10-27 22:09 ` Chen, Zide [this message]
2026-09-18 19:39 ` [PATCH v9 12/12] KVM: x86/pmu: Support RDPMC Metrics Clear Mode Zide Chen
2026-09-18 20:22 ` sashiko-bot
2026-09-18 21:08 ` Chen, Zide
2026-09-21 9:39 ` Mi, Dapeng
2026-10-27 22:56 ` Chen, Zide
2026-10-23 18:55 ` Jim Mattson
2026-10-27 22:17 ` Chen, Zide
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=6da36d01-c456-4bd9-8d3a-591e98ab3481@intel.com \
--to=zide.chen@intel.com \
--cc=Manali.Shukla@amd.com \
--cc=Sandipan.Das@amd.com \
--cc=ak@linux.intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=eranian@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=xudong.hao@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