From: "Chen, Zide" <zide.chen@intel.com>
To: Jim Mattson <jmattson@google.com>,
"Mi, Dapeng" <dapeng1.mi@linux.intel.com>
Cc: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Mingwei Zhang <mizhang@google.com>,
Das Sandipan <Sandipan.Das@amd.com>,
Shukla Manali <Manali.Shukla@amd.com>,
Falcon Thomas <thomas.falcon@intel.com>,
Xudong Hao <xudong.hao@intel.com>
Subject: Re: [PATCH v6 7/8] KVM: x86/pmu: Emulate RDPMC on performance metrics
Date: Thu, 23 Jul 2026 11:33:41 -0500 [thread overview]
Message-ID: <93d6d476-ed63-4c4f-9bf6-666101708eb6@intel.com> (raw)
In-Reply-To: <CALMp9eTOQJ1_QMazU3v_TAXupNfZTLsYta9wi7iRBy37P8WqTA@mail.gmail.com>
On 7/22/2026 10:10 PM, Jim Mattson wrote:
> On Wed, Jul 22, 2026 at 7:53 PM Mi, Dapeng <dapeng1.mi@linux.intel.com> wrote:
>>
>>
>> On 7/23/2026 10:25 AM, Jim Mattson wrote:
>>> On Wed, Jul 22, 2026 at 6:44 PM Mi, Dapeng <dapeng1.mi@linux.intel.com> wrote:
>>>>
>>>> On 7/23/2026 8:02 AM, Jim Mattson wrote:
>>>>> On Mon, Jun 29, 2026 at 4:29 PM Zide Chen <zide.chen@intel.com> wrote:
>>>>>> If the host has the PERF_METRICS capability but it's not present on
>>>>>> the guest, RDPMC interception must be enabled and KVM should inject
>>>>>> an #GP when the guest attempts a PERF_METRICS RDPMC.
>>>>>>
>>>>>> If the guest has PERF_METRICS but RDPMC interception is enabled for
>>>>>> other reasons, KVM needs to emulate RDPMC with type 2000H.
>>>>>>
>>>>>> For simplicity, Metrics Clear Mode is not supported.
>>>>>>
>>>>>> Signed-off-by: Zide Chen <zide.chen@intel.com>
>>>>>> ---
>>>>>> v6:
>>>>>> - Merge kvm_pmu_rdpmc_metrics() into intel_emulate_rdpmc().
>>>>>> - Reject non-zero index.
>>>>>> v5:
>>>>>> - new patch.
>>>>>> ---
>>>>>> arch/x86/kvm/pmu.c | 7 +++++++
>>>>>> arch/x86/kvm/vmx/pmu_intel.c | 14 ++++++++++++++
>>>>>> 2 files changed, 21 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>>>>>> index 8ef2d4761790..04b9c840f218 100644
>>>>>> --- a/arch/x86/kvm/pmu.c
>>>>>> +++ b/arch/x86/kvm/pmu.c
>>>>>> @@ -806,6 +806,12 @@ bool kvm_need_perf_global_ctrl_intercept(struct kvm_vcpu *vcpu)
>>>>>> }
>>>>>> EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_need_perf_global_ctrl_intercept);
>>>>>>
>>>>>> +static bool kvm_need_perf_metrics_intercept(struct kvm_vcpu *vcpu)
>>>>>> +{
>>>>>> + return (kvm_host.perf_capabilities & PERF_CAP_PERF_METRICS) &&
>>>>>> + !kvm_vcpu_has_perf_metrics(vcpu);
>>>>>> +}
>>>>>> +
>>>>>> bool kvm_need_rdpmc_intercept(struct kvm_vcpu *vcpu)
>>>>>> {
>>>>>> struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
>>>>>> @@ -818,6 +824,7 @@ bool kvm_need_rdpmc_intercept(struct kvm_vcpu *vcpu)
>>>>>> return true;
>>>>> I know we have a strong disagreement here, but I really feel that this
>>>>> must be secure and future-proof out of the box.
>>>>> What if we added a module parameter, enable_rdpmc_passthrough, which
>>>>> defaults to false?
>>>>>
>>>>> Then:
>>>>>
>>>>> if (!enable_rdpmc_passthrough)
>>>>> return true;
>>>>>
>>>>> Is that a reasonable compromise?
>>>> Yes, this is an option. Another option is to add a helper to explicitly
>>>> tell which platforms are secure and can pass-through rdpmc. Maybe like this,
>>>>
>>>> static bool intel_pmu_can_passthrough_rdpmc()
>>>> {
>>>> switch (boot_cpu_data.x86_vfm) {
>>>> case INTEL_ICELAKE_X:
>>>> case INTEL_SAPPHIRERAPIDS_X:
>>>> case INTEL_EMERALDRAPIDS_X:
>>>> case INTEL_GRANITERAPIDS_X:
>>>> ... ...
>>>> return true;
>>>> default:
>>>> return false;
>>>> }
>>>>
>>>> return false;
>>>> }
>>>>
>>>> Then rdpmc can be passed through by default on these known secure
>>>> platforms. For any new platforms, the rdpmc would be intercepted out of
>>>> box until we confirm it's secured and explicitly support them.
>>>>
>>>> How about this? At least for me, it looks like an overkill to disable rdpmc
>>>> passthrough unconditionally on these known secure platforms.
>>> The F/M match would only apply on bare metal, since you can't trust F/M in a VM.
>>>
>>> What if we combine this with the module parameter, but now the module
>>> parameter defaults to true? Somewhere in module load, we have:
>>>
>>> if (boot_cpu_has(X86_FEATURE_HYPERVISOR) || !intel_pmu_can_passthrough_rdpmc())
>>> enable_rdpmc_passthrough = false;
>>
>> It looks good to me. :)
>
> On second thought, it doesn't really matter if L0 has lied to L1 about
> F/M. If the hardware supports more RDPMC types than the L1 virtual CPU
> does, L0 must intercept and emulate RDPMC for vmcs01. Even if L1
> decides to pass through RDPMC to L2, L0 will still intercept and
> emulate RDPMC for vmcs02.
>
> So, we can drop the module parameter and just use
> intel_pmu_can_passthrough_rdpmc().
Thanks, will post a new version based on this.
> To keep the list short, I assume that any CPU with only three fixed
> counters will return true.
Will do some study on the available CPUs.
next prev parent reply other threads:[~2026-07-23 16:33 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 23:19 [PATCH V6 0/8] KVM: x86/pmu: Add hardware Topdown metrics support Zide Chen
2026-06-29 23:19 ` [PATCH v6 1/8] KVM: x86/pmu: Do not map fixed counters >= 3 to generic perf events Zide Chen
2026-06-30 2:13 ` Mi, Dapeng
2026-07-22 21:51 ` Jim Mattson
2026-06-29 23:19 ` [PATCH v6 2/8] KVM: x86/pmu: Support Intel fixed counter 3 on mediated vPMU Zide Chen
2026-06-30 2:16 ` Mi, Dapeng
2026-07-22 22:17 ` Jim Mattson
2026-07-23 15:36 ` Chen, Zide
2026-07-23 19:19 ` Jim Mattson
2026-06-29 23:19 ` [PATCH v6 3/8] KVM: x86/pmu: Rename and move vcpu_get_perf_capabilities() to pmu.h Zide Chen
2026-06-30 2:18 ` Mi, Dapeng
2026-07-22 22:47 ` Jim Mattson
2026-06-29 23:19 ` [PATCH v6 4/8] KVM: x86/pmu: Snapshot host IA32_PERF_CAPABILITIES in kvm_host Zide Chen
2026-06-30 2:19 ` Mi, Dapeng
2026-07-22 22:58 ` Jim Mattson
2026-06-29 23:19 ` [PATCH v6 5/8] KVM: x86/pmu: Support PERF_METRICS MSR in mediated vPMU Zide Chen
2026-06-30 2:20 ` Mi, Dapeng
2026-07-22 23:05 ` Jim Mattson
2026-07-23 16:30 ` Chen, Zide
2026-07-23 17:59 ` Jim Mattson
2026-07-23 23:44 ` Chen, Zide
2026-07-24 3:15 ` Jim Mattson
2026-07-24 20:47 ` Chen, Zide
2026-07-24 21:37 ` Jim Mattson
2026-07-24 22:59 ` Chen, Zide
2026-07-26 15:49 ` Jim Mattson
2026-07-27 15:34 ` Chen, Zide
2026-06-29 23:19 ` [PATCH v6 6/8] KVM: x86/pmu: Move RDPMC emulation into per-vendor callbacks Zide Chen
2026-06-30 2:23 ` Mi, Dapeng
2026-07-22 23:19 ` Jim Mattson
2026-06-29 23:19 ` [PATCH v6 7/8] KVM: x86/pmu: Emulate RDPMC on performance metrics Zide Chen
2026-06-30 2:23 ` Mi, Dapeng
2026-07-23 0:02 ` Jim Mattson
2026-07-23 1:44 ` Mi, Dapeng
2026-07-23 2:25 ` Jim Mattson
2026-07-23 2:52 ` Mi, Dapeng
2026-07-23 3:10 ` Jim Mattson
2026-07-23 5:47 ` Mi, Dapeng
2026-07-23 16:33 ` Chen, Zide [this message]
2026-07-23 19:08 ` Chen, Zide
2026-06-29 23:19 ` [PATCH v6 8/8] KVM: selftests: Add PERF_METRICS and fixed counter 3 tests Zide Chen
2026-06-30 2:36 ` Mi, Dapeng
2026-07-09 12:35 ` Jim Mattson
2026-07-10 8:08 ` Mi, Dapeng
2026-07-10 14:52 ` Chen, Zide
2026-07-13 6:57 ` Mi, Dapeng
2026-07-10 15:22 ` Jim Mattson
2026-07-13 7:11 ` Mi, Dapeng
2026-07-14 5:11 ` Jim Mattson
2026-07-14 5:28 ` Mi, Dapeng
2026-07-14 17:06 ` Jim Mattson
2026-07-21 19:17 ` Chen, Zide
2026-07-21 19:48 ` Jim Mattson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=93d6d476-ed63-4c4f-9bf6-666101708eb6@intel.com \
--to=zide.chen@intel.com \
--cc=Manali.Shukla@amd.com \
--cc=Sandipan.Das@amd.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=thomas.falcon@intel.com \
--cc=xudong.hao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome