From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: Zide Chen <zide.chen@intel.com>,
Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
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 v7 7/9] KVM: x86/pmu: Restrict RDPMC passthrough to known CPUs
Date: Fri, 31 Jul 2026 09:03:39 +0800 [thread overview]
Message-ID: <b270208f-e346-4d0e-9245-dd3c2b9a9676@linux.intel.com> (raw)
In-Reply-To: <CALMp9eTgxvqMYMr4+mGS0BwAE++Z0KW+Sb22r1QFwR-TdkUZMQ@mail.gmail.com>
On 7/30/2026 11:11 PM, Jim Mattson wrote:
> On Wed, Jul 29, 2026 at 7:51 PM Mi, Dapeng <dapeng1.mi@linux.intel.com> wrote:
>>
>> On 7/28/2026 3:21 AM, Zide Chen wrote:
>>> RDPMC type encodings are vendor-defined and could theoretically be
>>> extended on future CPUs. An unknown RDPMC type could leak host
>>> PMU information to the guest through RDPMC passthrough.
>>>
>>> Rather than assuming future CPUs are safe, explicitly permit only
>>> reviewed CPU models and require RDPMC interception everywhere else.
>>> This ensures RDPMC passthrough is enabled only on CPUs whose RDPMC
>>> encodings are audited and supported by KVM.
>>>
>>> Suggested-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>>> Suggested-by: Jim Mattson <jmattson@google.com>
>>> Signed-off-by: Zide Chen <zide.chen@intel.com>
>>> ---
>>> v7: new patch.
>>> ---
>>> arch/x86/kvm/pmu.c | 32 ++++++++++++++++++++++++++++++++
>>> 1 file changed, 32 insertions(+)
>>>
>>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>>> index 51c6d00a485f..092809bd757d 100644
>>> --- a/arch/x86/kvm/pmu.c
>>> +++ b/arch/x86/kvm/pmu.c
>>> @@ -77,6 +77,21 @@ static const struct x86_cpu_id vmx_pebs_pdist_cpu[] = {
>>> {}
>>> };
>>>
>>> +/*
>>> + * CPUs whose RDPMC encodings have been audited for KVM RDPMC
>>> + * passthrough support.
>>> + */
>>> +static const struct x86_cpu_id kvm_rdpmc_known_cpus[] = {
>>> + X86_MATCH_VFM(INTEL_ATOM_DARKMONT_X, NULL),
>>> + X86_MATCH_VFM(INTEL_LUNARLAKE_M, NULL),
>>> + X86_MATCH_VFM(INTEL_NOVALAKE, NULL),
>>> + X86_MATCH_VFM(INTEL_NOVALAKE_L, NULL),
>>> + X86_MATCH_VFM(INTEL_PANTHERLAKE_L, NULL),
>>> + X86_MATCH_VFM(INTEL_PANTHERLAKE_R, NULL),
>>> + X86_MATCH_VFM(INTEL_WILDCATLAKE_L, NULL),
>>> + {}
>>> +};
>>> +
>>> /* NOTE:
>>> * - Each perf counter is defined as "struct kvm_pmc";
>>> * - There are two types of perf counters: general purpose (gp) and fixed.
>>> @@ -807,6 +822,20 @@ 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_rdpmc_encoding_supported(void)
>>> +{
>>> + /* KVM understands all RDPMC encodings prior to PMU v6. */
>>> + if (kvm_host_pmu.version < 6)
>> I'm not sure if this works for AMD platforms. Jim said current AMD
>> platforms already have security holes and I believe the PMU version of AMD
>> platforms are less than 6.
> Let's not be pejorative! I said that AMD's RDPMC allows access to
> counters that KVM does not (yet) virtualize, such as the data fabric
> and L3 counters. The APM, volume 3, indicates that up to 28 counters
> are supported today. KVM only virtualizes 6.
I see. Thanks for clarifying this. My words were too arbitrary :(
Anyway, need @Sandipan and @Manali to double confirm this. If current
checks are not available for AMD platforms, we could need to introduce new
PMU vendor callbacks but not sure if it's worthy.
Thanks.
>
>> Need AMD guys to confirm. @Sandipan, @Manali.
next prev parent reply other threads:[~2026-07-31 1:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 19:21 [PATCH v7 0/9] KVM: x86/pmu: Add hardware Topdown metrics support Zide Chen
2026-07-27 19:21 ` [PATCH v7 1/9] KVM: x86/pmu: Do not map fixed counters >= 3 to generic perf events Zide Chen
2026-07-27 19:21 ` [PATCH v7 2/9] KVM: x86/pmu: Support Intel fixed counter 3 on mediated vPMU Zide Chen
2026-07-27 19:21 ` [PATCH v7 3/9] KVM: x86/pmu: Rename and move vcpu_get_perf_capabilities() to pmu.h Zide Chen
2026-07-27 19:21 ` [PATCH v7 4/9] KVM: x86/pmu: Snapshot host IA32_PERF_CAPABILITIES in kvm_host Zide Chen
2026-07-27 19:21 ` [PATCH v7 5/9] KVM: x86/pmu: Support PERF_METRICS MSR in mediated vPMU Zide Chen
2026-07-27 19:21 ` [PATCH v7 6/9] KVM: x86/pmu: Move RDPMC emulation into per-vendor callbacks Zide Chen
2026-07-27 19:21 ` [PATCH v7 7/9] KVM: x86/pmu: Restrict RDPMC passthrough to known CPUs Zide Chen
2026-07-30 2:51 ` Mi, Dapeng
2026-07-30 15:05 ` Chen, Zide
2026-07-31 0:50 ` Mi, Dapeng
2026-07-30 15:11 ` Jim Mattson
2026-07-31 1:03 ` Mi, Dapeng [this message]
2026-07-31 1:12 ` Mi, Dapeng
2026-07-27 19:21 ` [PATCH v7 8/9] KVM: x86/pmu: Emulate RDPMC on performance metrics Zide Chen
2026-07-27 19:21 ` [PATCH v7 9/9] KVM: selftests: Add PERF_METRICS and fixed counter 3 tests Zide Chen
2026-07-30 2:58 ` Mi, Dapeng
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=b270208f-e346-4d0e-9245-dd3c2b9a9676@linux.intel.com \
--to=dapeng1.mi@linux.intel.com \
--cc=Manali.Shukla@amd.com \
--cc=Sandipan.Das@amd.com \
--cc=ak@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 \
--cc=zide.chen@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