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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.