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

[Jim Mattson]

On Fri, Jul 10, 2026 at 1:08 AM Mi, Dapeng <dapeng1.mi@xxxxxxxxxxxxxxx> 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.

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.

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.