From: Sean Christopherson <seanjc@google.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Jinrong Liang <cloudliang@tencent.com>,
Like Xu <likexu@tencent.com>
Subject: [PATCH v5 02/13] KVM: x86/pmu: Don't enumerate support for fixed counters KVM can't virtualize
Date: Mon, 23 Oct 2023 17:26:22 -0700 [thread overview]
Message-ID: <20231024002633.2540714-3-seanjc@google.com> (raw)
In-Reply-To: <20231024002633.2540714-1-seanjc@google.com>
Hide fixed counters for which perf is incapable of creating the associated
architectural event. Except for the so called pseudo-architectural event
for counting TSC reference cycle, KVM virtualizes fixed counters by
creating a perf event for the associated general purpose architectural
event. If the associated event isn't supported in hardware, KVM can't
actually virtualize the fixed counter because perf will likely not program
up the correct event.
Note, this issue is almost certainly limited to running KVM on a funky
virtual CPU model, no known real hardware has an asymmetric PMU where a
fixed counter is supported but the associated architectural event is not.
Fixes: f5132b01386b ("KVM: Expose a version 2 architectural PMU to a guests")
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/pmu.h | 4 ++++
arch/x86/kvm/vmx/pmu_intel.c | 31 +++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index 1d64113de488..5341e8f69a22 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -19,6 +19,7 @@
#define VMWARE_BACKDOOR_PMC_APPARENT_TIME 0x10002
struct kvm_pmu_ops {
+ void (*init_pmu_capability)(void);
bool (*hw_event_available)(struct kvm_pmc *pmc);
struct kvm_pmc *(*pmc_idx_to_pmc)(struct kvm_pmu *pmu, int pmc_idx);
struct kvm_pmc *(*rdpmc_ecx_to_pmc)(struct kvm_vcpu *vcpu,
@@ -218,6 +219,9 @@ static inline void kvm_init_pmu_capability(const struct kvm_pmu_ops *pmu_ops)
pmu_ops->MAX_NR_GP_COUNTERS);
kvm_pmu_cap.num_counters_fixed = min(kvm_pmu_cap.num_counters_fixed,
KVM_PMC_MAX_FIXED);
+
+ if (pmu_ops->init_pmu_capability)
+ pmu_ops->init_pmu_capability();
}
static inline void kvm_pmu_request_counter_reprogram(struct kvm_pmc *pmc)
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 1b13a472e3f2..3316fdea212a 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -68,6 +68,36 @@ static int fixed_pmc_events[] = {
[2] = PSEUDO_ARCH_REFERENCE_CYCLES,
};
+static void intel_init_pmu_capability(void)
+{
+ int i;
+
+ /*
+ * Perf may (sadly) back a guest fixed counter with a general purpose
+ * counter, and so KVM must hide fixed counters whose associated
+ * architectural event are unsupported. On real hardware, this should
+ * never happen, but if KVM is running on a funky virtual CPU model...
+ *
+ * TODO: Drop this horror if/when KVM stops using perf events for
+ * guest fixed counters, or can explicitly request fixed counters.
+ */
+ for (i = 0; i < kvm_pmu_cap.num_counters_fixed; i++) {
+ int event = fixed_pmc_events[i];
+
+ /*
+ * Ignore pseudo-architectural events, they're a bizarre way of
+ * requesting events from perf that _can't_ be backed with a
+ * general purpose architectural event, i.e. they're guaranteed
+ * to be backed by the real fixed counter.
+ */
+ if (event < NR_REAL_INTEL_ARCH_EVENTS &&
+ (kvm_pmu_cap.events_mask & BIT(event)))
+ break;
+ }
+
+ kvm_pmu_cap.num_counters_fixed = i;
+}
+
static void reprogram_fixed_counters(struct kvm_pmu *pmu, u64 data)
{
struct kvm_pmc *pmc;
@@ -789,6 +819,7 @@ void intel_pmu_cross_mapped_check(struct kvm_pmu *pmu)
}
struct kvm_pmu_ops intel_pmu_ops __initdata = {
+ .init_pmu_capability = intel_init_pmu_capability,
.hw_event_available = intel_hw_event_available,
.pmc_idx_to_pmc = intel_pmc_idx_to_pmc,
.rdpmc_ecx_to_pmc = intel_rdpmc_ecx_to_pmc,
--
2.42.0.758.gaed0368e0e-goog
next prev parent reply other threads:[~2023-10-24 0:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 0:26 [PATCH v5 00/13] KVM: x86/pmu: selftests: Fixes and new tests Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 01/13] KVM: x86/pmu: Don't allow exposing unsupported architectural events Sean Christopherson
2023-10-24 0:26 ` Sean Christopherson [this message]
2023-10-24 0:26 ` [PATCH v5 03/13] KVM: x86/pmu: Always treat Fixed counters as available when supported Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 04/13] KVM: selftests: Add vcpu_set_cpuid_property() to set properties Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 05/13] KVM: selftests: Drop the "name" param from KVM_X86_PMU_FEATURE() Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 06/13] KVM: selftests: Extend {kvm,this}_pmu_has() to support fixed counters Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 07/13] KVM: selftests: Add pmu.h and lib/pmu.c for common PMU assets Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 08/13] KVM: selftests: Test Intel PMU architectural events on gp counters Sean Christopherson
2023-10-24 19:49 ` Sean Christopherson
2023-10-24 21:00 ` Sean Christopherson
2023-10-25 3:17 ` JinrongLiang
2023-10-26 20:38 ` Mingwei Zhang
2023-10-26 20:54 ` Sean Christopherson
2023-10-26 22:10 ` Mingwei Zhang
2023-10-26 22:54 ` Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 09/13] KVM: selftests: Test Intel PMU architectural events on fixed counters Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 10/13] KVM: selftests: Test consistency of CPUID with num of gp counters Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 11/13] KVM: selftests: Test consistency of CPUID with num of fixed counters Sean Christopherson
2023-10-24 11:40 ` JinrongLiang
2023-10-24 14:22 ` Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 12/13] KVM: selftests: Add functional test for Intel's fixed PMU counters Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 13/13] KVM: selftests: Extend PMU counters test to permute on vPMU version Sean Christopherson
2023-10-24 11:49 ` JinrongLiang
2023-10-24 14:23 ` Sean Christopherson
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=20231024002633.2540714-3-seanjc@google.com \
--to=seanjc@google.com \
--cc=cloudliang@tencent.com \
--cc=kvm@vger.kernel.org \
--cc=likexu@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.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