From: Sean Christopherson <seanjc@google.com>
To: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Jim Mattson <jmattson@google.com>,
Mingwei Zhang <mizhang@google.com>,
Xiong Zhang <xiong.y.zhang@intel.com>,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Like Xu <like.xu.linux@gmail.com>,
Jinrong Liang <cloudliang@tencent.com>,
Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [PATCH 1/2] KVM: x86/pmu: Define KVM_PMC_MAX_GENERIC for platform independence
Date: Thu, 20 Jun 2024 09:16:41 -0700 [thread overview]
Message-ID: <ZnRV6XrKkVwZB2TN@google.com> (raw)
In-Reply-To: <20240619182128.4131355-2-dapeng1.mi@linux.intel.com>
On Thu, Jun 20, 2024, Dapeng Mi wrote:
> The existing macro, KVM_INTEL_PMC_MAX_GENERIC, ambiguously represents the
> maximum supported General Purpose (GP) counter number for both Intel and
> AMD platforms. This could lead to issues if AMD begins to support more GP
> counters than Intel.
>
> To resolve this, a new platform-independent macro, KVM_PMC_MAX_GENERIC,
> is introduced to represent the maximum GP counter number across all x86
> platforms.
>
> No logic changes are introduced in this patch.
>
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> ---
> arch/x86/include/asm/kvm_host.h | 9 +++++----
> arch/x86/kvm/svm/pmu.c | 2 +-
> arch/x86/kvm/vmx/pmu_intel.c | 2 ++
> 3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 57440bda4dc4..18137be6504a 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -534,11 +534,12 @@ struct kvm_pmc {
>
> /* More counters may conflict with other existing Architectural MSRs */
> #define KVM_INTEL_PMC_MAX_GENERIC 8
> -#define MSR_ARCH_PERFMON_PERFCTR_MAX (MSR_ARCH_PERFMON_PERFCTR0 + KVM_INTEL_PMC_MAX_GENERIC - 1)
> -#define MSR_ARCH_PERFMON_EVENTSEL_MAX (MSR_ARCH_PERFMON_EVENTSEL0 + KVM_INTEL_PMC_MAX_GENERIC - 1)
> +#define KVM_AMD_PMC_MAX_GENERIC 6
> +#define KVM_PMC_MAX_GENERIC KVM_INTEL_PMC_MAX_GENERIC
Since we're changing the macro, maybe take the opportunity to use a better name?
E.g. KVM_MAX_NR_GP_COUNTERS? And then in a follow-up patch, give fixed counters
the same treatment, e.g. KVM_MAX_NR_FIXED_COUNTERS. Or maybe KVM_MAX_NR_GP_PMCS
and KVM_MAX_NR_FIXED_PMCS?
> +#define MSR_ARCH_PERFMON_PERFCTR_MAX (MSR_ARCH_PERFMON_PERFCTR0 + KVM_PMC_MAX_GENERIC - 1)
> +#define MSR_ARCH_PERFMON_EVENTSEL_MAX (MSR_ARCH_PERFMON_EVENTSEL0 + KVM_PMC_MAX_GENERIC - 1)
And I'm very, very tempted to say we should simply delete these two, along with
MSR_ARCH_PERFMON_FIXED_CTR_MAX, and just open code the "end" MSR in the one user.
Especially since "KVM" doesn't appear anyone in the name, i.e. because the names
misrepresent KVM's semi-arbitrary max as the *architectural* max.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6ad19d913d31..547dfe40d017 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7432,17 +7432,20 @@ static void kvm_probe_msr_to_save(u32 msr_index)
intel_pt_validate_hw_cap(PT_CAP_num_address_ranges) * 2))
return;
break;
- case MSR_ARCH_PERFMON_PERFCTR0 ... MSR_ARCH_PERFMON_PERFCTR_MAX:
+ case MSR_ARCH_PERFMON_PERFCTR0 ...
+ MSR_ARCH_PERFMON_PERFCTR0 + KVM_MAX_NR_GP_COUNTERS - 1:
if (msr_index - MSR_ARCH_PERFMON_PERFCTR0 >=
kvm_pmu_cap.num_counters_gp)
return;
break;
- case MSR_ARCH_PERFMON_EVENTSEL0 ... MSR_ARCH_PERFMON_EVENTSEL_MAX:
+ case MSR_ARCH_PERFMON_EVENTSEL0 ...
+ MSR_ARCH_PERFMON_EVENTSEL0 + KVM_MAX_NR_GP_COUNTERS - 1:
if (msr_index - MSR_ARCH_PERFMON_EVENTSEL0 >=
kvm_pmu_cap.num_counters_gp)
return;
break;
- case MSR_ARCH_PERFMON_FIXED_CTR0 ... MSR_ARCH_PERFMON_FIXED_CTR_MAX:
+ case MSR_ARCH_PERFMON_FIXED_CTR0 ...
+ MSR_ARCH_PERFMON_FIXED_CTR0 + KVM_MAR_NR_FIXED_COUNTERS - 1:
if (msr_index - MSR_ARCH_PERFMON_FIXED_CTR0 >=
kvm_pmu_cap.num_counters_fixed)
return;
> #define KVM_PMC_MAX_FIXED 3
> #define MSR_ARCH_PERFMON_FIXED_CTR_MAX (MSR_ARCH_PERFMON_FIXED_CTR0 + KVM_PMC_MAX_FIXED - 1)
> -#define KVM_AMD_PMC_MAX_GENERIC 6
>
> struct kvm_pmu {
> u8 version;
> @@ -554,7 +555,7 @@ struct kvm_pmu {
> u64 global_status_rsvd;
> u64 reserved_bits;
> u64 raw_event_mask;
> - struct kvm_pmc gp_counters[KVM_INTEL_PMC_MAX_GENERIC];
> + struct kvm_pmc gp_counters[KVM_PMC_MAX_GENERIC];
> struct kvm_pmc fixed_counters[KVM_PMC_MAX_FIXED];
>
> /*
> diff --git a/arch/x86/kvm/svm/pmu.c b/arch/x86/kvm/svm/pmu.c
> index 6e908bdc3310..2fca247798eb 100644
> --- a/arch/x86/kvm/svm/pmu.c
> +++ b/arch/x86/kvm/svm/pmu.c
> @@ -218,7 +218,7 @@ static void amd_pmu_init(struct kvm_vcpu *vcpu)
> int i;
>
> BUILD_BUG_ON(KVM_AMD_PMC_MAX_GENERIC > AMD64_NUM_COUNTERS_CORE);
> - BUILD_BUG_ON(KVM_AMD_PMC_MAX_GENERIC > INTEL_PMC_MAX_GENERIC);
> + BUILD_BUG_ON(KVM_AMD_PMC_MAX_GENERIC > KVM_PMC_MAX_GENERIC);
>
> for (i = 0; i < KVM_AMD_PMC_MAX_GENERIC ; i++) {
> pmu->gp_counters[i].type = KVM_PMC_GP;
> diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
> index fb5cbd6cbeff..a4b0bee04596 100644
> --- a/arch/x86/kvm/vmx/pmu_intel.c
> +++ b/arch/x86/kvm/vmx/pmu_intel.c
> @@ -570,6 +570,8 @@ static void intel_pmu_init(struct kvm_vcpu *vcpu)
> struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
> struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu);
>
> + BUILD_BUG_ON(KVM_INTEL_PMC_MAX_GENERIC > KVM_PMC_MAX_GENERIC);
Rather than BUILD_BUG_ON() for both Intel and AMD, can't we just do?
#define KVM_MAX_NR_GP_COUNTERS max(KVM_INTEL_PMC_MAX_GENERIC, KVM_AMD_PMC_MAX_GENERIC)
> +
> for (i = 0; i < KVM_INTEL_PMC_MAX_GENERIC; i++) {
> pmu->gp_counters[i].type = KVM_PMC_GP;
> pmu->gp_counters[i].vcpu = vcpu;
> --
> 2.34.1
>
next prev parent reply other threads:[~2024-06-20 16:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 18:21 [PATCH 0/2] KVM vPMU code refine Dapeng Mi
2024-06-19 18:21 ` [PATCH 1/2] KVM: x86/pmu: Define KVM_PMC_MAX_GENERIC for platform independence Dapeng Mi
2024-06-20 16:16 ` Sean Christopherson [this message]
2024-06-21 2:35 ` Mi, Dapeng
2024-06-21 13:48 ` Sean Christopherson
2024-06-19 18:21 ` [PATCH 2/2] selftests: kvm: Reduce verbosity of "Random seed" messages Dapeng Mi
2024-06-20 18:13 ` Sean Christopherson
2024-06-21 2:51 ` Mi, Dapeng
2024-06-21 13:29 ` Sean Christopherson
2024-06-26 1:57 ` Mi, Dapeng
2024-06-20 16:07 ` [PATCH 0/2] KVM vPMU code refine Sean Christopherson
2024-06-21 0:28 ` 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=ZnRV6XrKkVwZB2TN@google.com \
--to=seanjc@google.com \
--cc=cloudliang@tencent.com \
--cc=dapeng1.mi@intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=xiong.y.zhang@intel.com \
--cc=zhenyuw@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.