Re: [PATCH v9 11/12] KVM: x86/pmu: Reject writes to reserved MSR_PERF_METRICS bits

[Jim Mattson <jmattson@google.com>]

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? 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.