From: sashiko-bot@kernel.org
To: "Zide Chen" <zide.chen@intel.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v9 12/12] KVM: x86/pmu: Support RDPMC Metrics Clear Mode
Date: Fri, 18 Sep 2026 20:22:00 +0000 [thread overview]
Message-ID: <20260918202200.F39971F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260918193937.569414-13-zide.chen@intel.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] pmu: event filter mistakenly strips METRICS_CLEAR_EN from fixed_ctr_ctrl_hw
- [Medium] pmu: METRICS_CLEAR_EN unmasked without validating fixed counter bounds
- [Low] pmu: emulation incorrectly ties PERF_METRICS clearing to SLOTS PMC existence
--
commit 8ba3725c32dbde4a1c3935cb433e898e06425b83
Author: Zide Chen <zide.chen@intel.com>
KVM: x86/pmu: Support RDPMC Metrics Clear Mode
This commit adds support for PERF_CAP_RDPMC_METRICS_CLEAR (bit 19 of
IA32_PERF_CAPABILITIES). It advertises this capability to guests when the
mediated PMU is enabled and the host reports it, unmasking the relevant
control bit. It also updates intel_emulate_rdpmc() to replicate the
clear-on-read behavior for consistency.
> diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
> index 98e2fb80347a1..3e5e8bae67ab0 100644
> --- a/arch/x86/kvm/vmx/pmu_intel.c
> +++ b/arch/x86/kvm/vmx/pmu_intel.c
[ ... ]
> @@ -138,6 +149,18 @@ static int intel_emulate_rdpmc(struct kvm_vcpu *vcpu, unsigned int idx,
> return 1;
>
> *data = pmu->perf_metrics;
> +
> + /*
> + * Per the SDM, RDPMC of PERF_METRICS clears both PERF_METRICS
> + * and the SLOTS fixed counter when Metrics Clear Mode is
> + * enabled via INTEL_FIXED_3_METRICS_CLEAR in FIXED_CTR_CTRL.
> + */
> + pmc = kvm_pmc_idx_to_pmc(pmu, INTEL_PMC_IDX_FIXED_SLOTS);
> + if (pmc && intel_pmu_metrics_clear_enabled(pmu)) {
> + pmu->perf_metrics = 0;
> + pmc_write_counter(pmc, 0);
> + }
> +
[Severity: Low]
Does tying the clearing of PERF_METRICS to the existence of the SLOTS PMC in
intel_emulate_rdpmc() violate the hardware specification?
If the guest executes RDPMC natively and triggers an interception, and the
SLOTS counter is not exposed to the guest (making kvm_pmc_idx_to_pmc return
NULL), but METRICS_CLEAR_EN is enabled, this code silently skips clearing
PERF_METRICS.
Should the clearing of pmu->perf_metrics be performed independently of whether
the software PMC object for the SLOTS counter exists?
> return 0;
> default:
> return 1;
[ ... ]
> @@ -601,6 +624,11 @@ static void intel_pmu_refresh(struct kvm_vcpu *vcpu)
> INTEL_FIXED_0_USER |
> INTEL_FIXED_0_ENABLE_PMI);
>
> + if (perf_capabilities & PERF_CAP_RDPMC_METRICS_CLEAR)
> + pmu->fixed_ctr_ctrl_rsvd &=
> + ~intel_fixed_bits_by_idx(INTEL_FIXED_SLOTS_IDX,
> + INTEL_FIXED_3_METRICS_CLEAR);
> +
[Severity: Medium]
Does intel_pmu_refresh() unconditionally unmask the METRICS_CLEAR_EN bit
without verifying if the guest topology actually exposes the SLOTS counter?
If a VM is configured with 3 or fewer fixed counters, this unmasking would
allow the unprivileged guest OS to write to bit 14 in
MSR_CORE_PERF_FIXED_CTR_CTRL without triggering the expected #GP.
Should this be gated by checking if pmu->nr_arch_fixed_counters >
INTEL_FIXED_SLOTS_IDX?
[Severity: High]
Does this patch inadvertently cause event filters to strip the METRICS_CLEAR_EN
bit in kvm_mediated_pmu_refresh_event_filter()?
When a host-level event filter denies the SLOTS counter (counter 3) from
counting, KVM applies a 0xf hardware mask that zeroes all 4 configuration bits
for the counter:
arch/x86/kvm/pmu.c:kvm_mediated_pmu_refresh_event_filter() {
...
} else {
u64 mask = intel_fixed_bits_by_idx(pmc->idx - KVM_FIXED_PMC_BASE_IDX, 0xf);
pmu->fixed_ctr_ctrl_hw &= ~mask;
if (allowed)
pmu->fixed_ctr_ctrl_hw |= pmu->fixed_ctr_ctrl & mask;
}
}
Since this mask covers the entire 4-bit configuration block, it will also clear
bit 14 (METRICS_CLEAR_EN) from hardware. If the guest sets METRICS_CLEAR_EN and
then executes RDPMC natively, it will lead to un-cleared stale metrics.
Should the mask be updated to avoid interfering with this newly introduced
feature bit?
> counter_rsvd = ~((BIT_ULL(pmu->nr_arch_gp_counters) - 1) |
> ((BIT_ULL(pmu->nr_arch_fixed_counters) - 1) << KVM_FIXED_PMC_BASE_IDX));
> pmu->global_ctrl_rsvd = counter_rsvd;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918193937.569414-1-zide.chen@intel.com?part=12
next prev parent reply other threads:[~2026-09-18 20:22 UTC|newest]
Thread overview: 23+ 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-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-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-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-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 [this message]
2026-09-18 21:08 ` Chen, Zide
2026-09-21 9:39 ` Mi, Dapeng
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=20260918202200.F39971F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zide.chen@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