Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Zide Chen" <zide.chen@intel.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH V4 3/4] KVM: x86/pmu: Support PERF_METRICS MSR in mediated vPMU
Date: Tue, 23 Jun 2026 04:48:25 +0000	[thread overview]
Message-ID: <20260623044826.592FF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260623041927.178256-4-zide.chen@intel.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Emulation of guest RDMSR and WRMSR for MSR_PERF_METRICS unconditionally injects a #GP fault, breaking emulation and nested virtualization.
- [High] KVM_SET_MSRS for MSR_PERF_METRICS is silently discarded, breaking live migration of TMA metrics.
- [High] Host Topdown microarchitectural metrics are leaked to the guest via the RDPMC instruction when mediated PMU is enabled but the guest lacks the PERF_METRICS capability.
--

commit 3d014d661f0ac59ad10f0335ced10697e72d7bf6
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
Subject: KVM: x86/pmu: Support PERF_METRICS MSR in mediated vPMU

This commit exposes the IA32_PERF_METRICS MSR to the guest when mediated vPMU
is enabled. It handles the MSR in kvm_pmu_{get,set}_msr() for host accesses
and saves/restores the value on PMU context switches to avoid clobbering host
data or leaking guest state.

> diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
> index 59b7a90c79e12..2c3367f5e2dfb 100644
> --- a/arch/x86/kvm/vmx/pmu_intel.c
> +++ b/arch/x86/kvm/vmx/pmu_intel.c
[ ... ]
> @@ -345,6 +347,11 @@ static int intel_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  	case MSR_CORE_PERF_FIXED_CTR_CTRL:
>  		msr_info->data = pmu->fixed_ctr_ctrl;
>  		break;
> +	case MSR_PERF_METRICS:
> +		if (!msr_info->host_initiated)
> +			return 1;

[Severity: High]
If KVM needs to emulate a guest RDMSR instruction targeting MSR_PERF_METRICS,
won't this unconditional return inject a #GP fault into the guest?

> +		msr_info->data = pmu->perf_metrics;
> +		break;
>  	case MSR_IA32_PEBS_ENABLE:
>  		msr_info->data = pmu->pebs_enable;
>  		break;
> @@ -394,6 +401,16 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  		if (pmu->fixed_ctr_ctrl != data)
>  			reprogram_fixed_counters(pmu, data);
>  		break;
> +	case MSR_PERF_METRICS:
> +		if (!msr_info->host_initiated)
> +			return 1;

[Severity: High]
Similarly, if KVM emulates a guest WRMSR instruction targeting
MSR_PERF_METRICS, does returning 1 here cause the emulator to incorrectly
inject a #GP fault?

> +
> +		/*
> +		 * If TMA level 2 is not supported, bits [63:32] are reserved
> +		 * and ignored on write, so no validation is needed here.
> +		 */
> +		pmu->perf_metrics = data;

[Severity: High]
When restoring guest state during live migration, userspace calls KVM_SET_MSRS
which is wrapped in vcpu_load() and vcpu_put(). Since intel_pmu_set_msr()
updates pmu->perf_metrics without updating the hardware MSR, won't the
subsequent intel_mediated_pmu_put() during vcpu_put() read the stale hardware
MSR and overwrite this newly restored value?

> +		break;
>  	case MSR_IA32_PEBS_ENABLE:
>  		if (data & pmu->pebs_enable_rsvd)
>  			return 1;
[ ... ]
> @@ -803,6 +828,13 @@ static void intel_mediated_pmu_load(struct kvm_vcpu *vcpu)
>  	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
>  	u64 global_status, toggle;
>  
> +	/*
> +	 * PERF_METRICS MSR must be restored closely after fixed counter 3,
> +	 * which was just restored by kvm_pmu_load_guest_pmcs().
> +	 */
> +	if (vcpu_has_perf_metrics(vcpu))
> +		wrmsrq(MSR_PERF_METRICS, pmu->perf_metrics);
> +

[Severity: High]
If the guest is configured without PERF_CAP_PERF_METRICS but with mediated
PMU enabled, RDPMC exiting might be disabled. Since
intel_mediated_pmu_load() skips writing to MSR_PERF_METRICS in this case,
could the guest execute RDPMC and read the un-scrubbed host metrics, leaking
host microarchitectural state?

>  	rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, global_status);
>  	toggle = pmu->global_status ^ global_status;
>  	if (global_status & toggle)
> @@ -831,6 +863,12 @@ static void intel_mediated_pmu_put(struct kvm_vcpu *vcpu)
>  	 */
>  	if (pmu->fixed_ctr_ctrl_hw)
>  		wrmsrq(MSR_CORE_PERF_FIXED_CTR_CTRL, 0);
> +
> +	if (vcpu_has_perf_metrics(vcpu)) {
> +		pmu->perf_metrics = rdpmc(INTEL_PMC_FIXED_RDPMC_METRICS);
> +		if (pmu->perf_metrics)
> +			wrmsrq(MSR_PERF_METRICS, 0);
> +	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623041927.178256-1-zide.chen@intel.com?part=3

  reply	other threads:[~2026-06-23  4:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23  4:19 [PATCH V4 0/4] KVM: x86/pmu: Add hardware Topdown metrics support Zide Chen
2026-06-23  4:19 ` [PATCH V4 1/4] KVM: x86/pmu: Do not map fixed counters >= 3 to generic perf events Zide Chen
2026-06-23  4:19 ` [PATCH V4 2/4] KVM: x86/pmu: Support Intel fixed counter 3 on mediated vPMU Zide Chen
2026-06-23  4:19 ` [PATCH V4 3/4] KVM: x86/pmu: Support PERF_METRICS MSR in " Zide Chen
2026-06-23  4:48   ` sashiko-bot [this message]
2026-06-23  7:04   ` Mi, Dapeng
2026-06-23  4:19 ` [PATCH V4 4/4] KVM: selftests: Add perf_metrics and fixed counter 3 tests Zide Chen
2026-06-23  4:43   ` sashiko-bot

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=20260623044826.592FF1F000E9@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