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

[Chen, Zide]

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.