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

[Mi, Dapeng]

On 7/10/2026 10:52 PM, Chen, Zide wrote:
>
> 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);
>  }

Yes, it looks good for me. guest_test_rdpmc() can cover both the
interception and pass-through cases for rdpmc. 


>