Re: [PATCH v6 8/8] KVM: selftests: Add PERF_METRICS and fixed counter 3 tests

["Mi, Dapeng" <dapeng1.mi@linux.intel.com>]

On 7/10/2026 11:22 PM, Jim Mattson wrote:
> On Fri, Jul 10, 2026 at 1:08 AM Mi, Dapeng <dapeng1.mi@linux.intel.com> wrote:
>>
>> On 7/9/2026 8:35 PM, Jim Mattson wrote:
>>> On Mon, Jun 29, 2026 at 7:36 PM Mi, Dapeng <dapeng1.mi@linux.intel.com> wrote:
>>>> On 6/30/2026 7:19 AM, Zide Chen wrote:
>>>>> Add a test case to exercise IA32_PERF_METRICS, i.e. architectural
>>>>> support for Topdown (TMA) Level 1 metrics, enumerated by
>>>>> IA32_PERF_CAPABILITIES[15].
>>>>>
>>>>> Only check for non-zero metrics, as they are derived and depend on
>>>>> the workload, CPU model, and host scheduling, making precise
>>>>> expectations fragile.
>>>>>
>>>>> Extend the PMU selftest to cover Intel fixed counter 3 by bumping
>>>>> MAX_NR_FIXED_COUNTERS to 4 and validating basic functionality.
>>>>>
>>>>> Signed-off-by: Zide Chen <zide.chen@intel.com>
>>>>> ---
>>>>> ...
>>>>> +static void __guest_test_perf_metrics(void)
>>>>> +{
>>>>> +     int retiring, bad_spec, fe_bound, be_bound, sum;
>>>>> +     u64 global_ctrl, metrics;
>>>>> +
>>>>> +     if ((guest_get_pmu_version() < 2) ||    /* Does guest have GLOBAL_CTRL? */
>>>>> +         !this_cpu_has(X86_FEATURE_PDCM) ||
>>>>> +         !(rdmsr(MSR_IA32_PERF_CAPABILITIES) & PERF_CAP_PERF_METRICS))
>>>>> +             return;
>>>>> +
>>>>> +     wrmsr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
>>>>> +     wrmsr(MSR_CORE_PERF_FIXED_CTR3, 0);
>>>>> +     wrmsr(MSR_PERF_METRICS, 0);
>>>>> +
>>>>> +     /* Enable fixed ctr3 (TOPDOWN.SLOTS) and PERF_METRICS. */
>>>>> +     wrmsr(MSR_CORE_PERF_FIXED_CTR_CTRL, FIXED_PMC_CTRL(3, FIXED_PMC_KERNEL));
>>>>> +     global_ctrl = FIXED_PMC_GLOBAL_CTRL_ENABLE(3) |
>>>>> +                   PERF_METRICS_GLOBAL_CTRL_ENABLE;
>>>>> +
>>>>> +     GUEST_RUN_PAYLOAD(MSR_CORE_PERF_GLOBAL_CTRL, global_ctrl, "");
>>>>> +
>>>>> +     /* Check test results. */
>>>>> +     metrics = rdmsr(MSR_PERF_METRICS);
>>>> Could we use rdpmc instead of rdmsr here? rdpmc is a preferred way to read
>>>> counter value.
>>> This is in-guest code, so the unintercepted RDMSR will be much faster
>>> than the emulated RDPMC.
>>>
>>> Should we rethink that preference, or add hardware support for
>>> selective RDPMC intercepts?
>> Hmm, in current most cases, rdpmc and rdmsr should share consistent
>> interception configuration for PERF_METRICS except host and guest have
>> different counters bitmap.
> I'm assuming that Intel wants to reserve the right to cover other
> resources with RDPMC in the future. Unless we have some way of
> determining, through a hardware enumeration, that all readable
> resources contain guest state, then we will akways have to intercept
> RDPMC.

rdpmc is the preferable way to read PMU counters since the better
performance than rdmsr, and most of current code regardless of kernel or
user-space already use rdpmc to read PMC counters. If we set the rdpmc to
interception by default, then it may cause extra performance hit.

Currently I didn't hear there is any plan to extend the rdpmc to support
more types for Intel platforms ...


>
> If I'm wrong, and Intel is willing to guarantee that no new resources
> will ever be added, then we can let the guest execute RDPMC natively,
> when the guest owns all of the counters and  PERF_METRICS.
>