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

[Chen, Zide]

On 7/10/2026 3:08 AM, Mi, Dapeng wrote:
> 
> On 7/9/2026 8:35 PM, Jim Mattson wrote:
>> On Mon, Jun 29, 2026 at 7:36 PM Mi, Dapeng <dapeng1.mi@xxxxxxxxxxxxxxx> 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@xxxxxxxxx>
>>>> ---
>>>> ...
>>>> +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.
> 
> Considering this is a test case, the test coverage should be more important
> than the performance, there should be at least a place to call rdpmc
> against the PERF_METRICS, otherwise, that path won't be validated. 

How about keeping rdmsr() in __guest_test_perf_metrics(), and using
RDPMC in the sanity test?

@@ -369,7 +371,7 @@ static void __guest_test_perf_metrics(void)
        GUEST_ASSERT_EQ(rdmsr(MSR_PERF_METRICS), metrics);
        wrmsr(MSR_PERF_METRICS, 0xdeaddead);

-       GUEST_ASSERT_EQ(rdmsr(MSR_PERF_METRICS), 0xdeaddead);
+       guest_test_rdpmc(INTEL_RDPMC_METRICS, true, 0xdeaddead);
 }

>