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

[Jim Mattson]

On Tue, Jul 21, 2026 at 12:17 PM Chen, Zide <zide.chen@xxxxxxxxx> wrote:
>
>
>
> On 7/14/2026 12:06 PM, Jim Mattson wrote:
> > On Mon, Jul 13, 2026 at 10:28 PM Mi, Dapeng <dapeng1.mi@xxxxxxxxxxxxxxx> wrote:
> >>
> >>
> >> On 7/14/2026 1:11 PM, Jim Mattson wrote:
> >>> On Mon, Jul 13, 2026 at 12:12 AM Mi, Dapeng <dapeng1.mi@xxxxxxxxxxxxxxx> wrote:
> >>>
> >>>> 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 ...
> >>> Is Intel willing to commit to that?
> >>
> >> I'm afraid not. :(
> >
> > Then, KVM must always intercept RDPMC.
> >
> >> rdpmc is still possible to be extended to support more types in the future,
> >> but recently we don't see such requirements.
> >
> > That's no comfort.
> >
> > An alternative would be for Intel to provide a way for KVM to query
> > which types of PMC are supported in ECX[31:16], before or concurrently
> > with any microarchitecture that supports more types than CPUs support
> > today.
>
> While I can't speak for future Intel architectures, we're not aware of
> any plans to extend RDPMC with additional resource types in the
> foreseeable future.
>
> Regarding the proposed enumeration mechanism, I'm not sure it changes
> the fundamental situation. Even if a future architecture provides an
> enumeration mechanism for new RDPMC resource types, RDPMC passthrough on
> an older KVM could still exist until KVM gains support for the new
> resource types.
>
> Given that, I'm not sure the possibility of a future RDPMC extension by
> itself is sufficient justification for intercepting RDPMC
> unconditionally today. RDPMC is the standard low-overhead interface for
> reading PMU data, and forcing every RDPMC through a VM-Exit would impose
> a significant performance penalty.

I *am* sure. If passing through RDPMC could leak host-level
information on future hardware, then KVM must not pass through RDPMC.
Full stop.

Note that KVM cannot pass through RDPMC on AMD hardware today, because
AMD's RDPMC already leaks host resources (e.g. data fabric PMCs).