Re: [PATCH v6 5/8] KVM: x86/pmu: Support PERF_METRICS MSR in mediated vPMU

["Chen, Zide" <zide.chen@intel.com>]

On 7/24/2026 4:37 PM, Jim Mattson wrote:
> On Fri, Jul 24, 2026 at 1:47 PM Chen, Zide <zide.chen@intel.com> wrote:
>>
>>
>>
>> On 7/23/2026 10:15 PM, Jim Mattson wrote:
>>> On Thu, Jul 23, 2026 at 4:44 PM Chen, Zide <zide.chen@intel.com> wrote:
>>>> The SDM guidance that "fixed counter 3 must be restored before
>>>> PERF_METRICS" appears to apply only to a running PMU, which is not the
>>>> case here.
>>>
>>> That's not my reading of the SDM. There are three bullet points about
>>> save/restore at the end of volume 3, section 22.3.9.3:
>>>
>>> * PERF_METRICS and fixed-function performance-monitoring counter 3
>>> should be saved and restored together.
>>> * To ensure that PERF_METRICS and fixed-function
>>> performance-monitoring counter 3 remain synchronized,
>>> both should be disabled during both save and restore. Software should
>>> enable/disable them atomically, with a
>>> single write to IA32_PERF_GLOBAL_CTRL to set/clear both
>>> EN_PERF_METRICS[bit 48] and
>>> EN_FIXED_CTR3[bit 35].
>>> * On state restore, fixed-function performance-monitoring counter 3
>>> must be restored before PERF_METRICS,
>>> otherwise undefined results may be observed.
>>>
>>> The second bullet contradicts your claim above.
>>
>> Thanks for pointing this out. I followed up with an internal ucode
>> expert, and my earlier explanation was incorrect.
>>
>> The ordering requirement is not dependent on whether the PMU is enabled.
>> The relevant recalculation happens on the WRMSR itself, so the SDM
>> guidance to restore fixed counter 3 before PERF_METRICS still applies
>> even when counting is disabled.
>>
>> That said, for the code path being discussed, both PERF_METRICS and
>> fixed counter 3 are written with 0. I was advised that this specific
>> all-zero case still converges to the intended hardware state regardless
>> of write order, so the write ordering here does not affect the final result.
>>
>> Sorry for the confusion, and thanks for the correction.
> 
> At the very least, the reliance on an undocumented exception to the
> requirement stated in the SDM warrants an explicit comment.

Yes, will do.