Re: [PATCH v9 05/12] KVM: x86/pmu: Support PERF_METRICS MSR in mediated vPMU

[Chen, Zide]

On 10/29/2026 4:28 PM, Yosry Ahmed wrote:
> On Tue, Oct 27, 2026 at 2:31 PM Chen, Zide <zide.chen@xxxxxxxxx> wrote:
>>
>>
>>
>> On 10/23/2026 1:27 PM, Jim Mattson wrote:
>>> On Fri, Sep 18, 2026 at 12:39 PM Zide Chen <zide.chen@xxxxxxxxx> wrote:
>>>>
>>>> +static inline bool kvm_vcpu_has_perf_metrics(struct kvm_vcpu *vcpu)
>>>> +{
>>>> +    return kvm_vcpu_get_perf_caps(vcpu) & PERF_CAP_PERF_METRICS;
>>>> +}
>>>
>>> The SDM, volume 3, section 22.3.9.3, says:
>>>
>>>> IA32_PERF_GLOBAL_CTRL. EN_PERF_METRICS[48]: If this bit is set *and*
>>>> fixed-function performance-monitoring counter 3 is enabled, built-in
>>>> performance metrics are enabled. [emphasis mine]
>>>
>>> and
>>>
>>>> The values in MSR_PERF_METRICS are derived from fixed-function
>>>> performance-monitoring counter 3.
>>>
>>> Hence, a dependency on fixed counter 3 belongs in this predicate.
>>> Perhaps something like:
>>>
>>>       static inline bool kvm_pmu_has_fixed_counter(struct kvm_pmu *pmu,
>>>                                                    unsigned int idx)
>>>       {
>>>               return idx < pmu->nr_arch_fixed_counters;
>>>       }
>>>
>>>       static inline bool kvm_vcpu_has_perf_metrics(struct kvm_vcpu *vcpu)
>>>       {
>>>               return (kvm_vcpu_get_perf_caps(vcpu) & PERF_CAP_PERF_METRICS) &&
>>>                      kvm_pmu_has_fixed_counter(vcpu_to_pmu(vcpu),
>>>                                                INTEL_PMC_IDX_FIXED_SLOTS -
>>>                                                INTEL_PMC_IDX_FIXED);
>>>       }
>>>
>>> with intel_pmu_refresh() calling kvm_vcpu_has_perf_metrics() instead of
>>> testing perf_capabilities directly. (nr_arch_fixed_counters has already
>>> been computed at that point; all_valid_pmc_idx has not.)
>>
>> Thanks for the detailed analysis. That makes total sense.
>>
>> Initially I didn't gate PERF_METRICS on fixed counter 3 out of concern
>> about policing userspace configurations. Additionally, as in the quoted
>> SDM text above, it means PERF_METRICS can't function without fixed
>> counter 3, but strictly speaking, the SDM doesn't prevent other
>> operations, for example, writing the METRICS_CLEAR_EN bit.
>>
>> But having IA32_PERF_CAPABILITIES[15] set in the absence of FC3 is not
>> going to happen natively, so I think it doesn't break any rules if KVM
>> chooses to gate PERF_METRICS on FC3. And as you pointed out, it's a
>> simple and effective way to protect KVM invariants and migration integrity.
>>
>> I will add the FC3 check to kvm_vcpu_has_perf_metrics().
> 
> If userspace sets IA32_PERF_CAPABILITIES[15] but not FC3 (for some
> reason), I think architecturally it should still be valid to
> read/write PERF_METRICS. KVM disallowing access to PERF_METRICS while
> IA32_PERF_CAPABILITIES[15] is set would not be correct
> architecturally, right?

Right. Per SDM 22.8, MSR_PERF_METRICS is available as long as
IA32_PERF_CAPABILITIES[15] is set, so disallowing access to it when bit
15 is exposed seems architecturally incorrect. However, TMA metrics
cannot be enabled or computed without FC3 (SDM 22.3.9.3).

Instead of gating kvm_vcpu_has_perf_metrics() on FC3, seems it's better
off to do some changes to fix the invariants where they belong:
1. Untie FC3 from kvm_vcpu_has_perf_metrics() so the MSR remains accessible.
2. In intel_pmu_refresh(), compute perf_metrics_rsvd before the PMU v1
early return so save/restore works properly.
3. Explicitly check for FC3 when unmasking GLOBAL_CTRL[48] (TMA enable)
and FIXED_CTR_CTRL[14] (METRICS_CLEAR_EN), and guard pmc in RDPMC emulation.

This seems satisfy the SDM while keeping migration and invariants intact.