From: Sean Christopherson <seanjc@google.com>
To: Like Xu <like.xu.linux@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jim Mattson <jmattson@google.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] KVM: x86/pmu: Limit the maximum number of supported Intel GP counters
Date: Fri, 7 Oct 2022 20:02:36 +0000 [thread overview]
Message-ID: <Y0CF3F/pJOBnY1Xz@google.com> (raw)
In-Reply-To: <20220919091008.60695-2-likexu@tencent.com>
On Mon, Sep 19, 2022, Like Xu wrote:
> From: Like Xu <likexu@tencent.com>
>
> The Intel Architectural IA32_PMCx MSRs addresses range allows for
> a maximum of 8 GP counters. A local macro (named KVM_INTEL_PMC_MAX_GENERIC)
> is introduced to take back control of this virtual capability to avoid
> errors introduced by the out-of-bound counter emulations.
Phrase changelogs as commands.
> Suggested-by: Jim Mattson <jmattson@google.com>
> Signed-off-by: Like Xu <likexu@tencent.com>
> Reviewed-by: Jim Mattson <jmattson@google.com>
> ---
> arch/x86/include/asm/kvm_host.h | 6 +++++-
> arch/x86/kvm/pmu.c | 2 +-
> arch/x86/kvm/vmx/pmu_intel.c | 4 ++--
> arch/x86/kvm/x86.c | 12 +++++++-----
> 4 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 2c96c43c313a..17abcf5c496a 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -501,6 +501,10 @@ struct kvm_pmc {
> bool intr;
> };
>
> +/* More counters may conflict with other existing Architectural MSRs */
> +#define KVM_INTEL_PMC_MAX_GENERIC 8
This is weird and backwards. Common x86 code shouldn't "prefer" Intel over AMD,
or vice versa. Similar to KVM_MAX_NR_USER_RETURN_MSRS, the way to do this is to
define KVM's common software limit, and then verify that the vendor limits are
below that common limit. E.g.
#define KVM_MAX_NR_PMU_GP_COUNTERS 8
and then add compile-time assertions that Intel stays below the max (and obviously
AMD as well).
> +#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)
These are Intel specific, correct? I.e. "arch" means "Intel architectural MSRs"?
The perf-defined names are out of KVM's control, but adding what appears to be
generic #defines in common KVM that are actually Intel specific is confusing.
Given that there's only a single user, I think the easiest thing is to just open
code the users, e.g.
case MSR_ARCH_PERFMON_PERFCTR0 ...
MSR_ARCH_PERFMON_PERFCTR0 + KVM_MAX_NR_PMU_GP_COUNTERS - 1:
if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_PERFCTR0 >=
min(KVM_MAX_NR_PMU_GP_COUNTERS, kvm_pmu_cap.num_counters_gp))
continue;
break;
case MSR_ARCH_PERFMON_EVENTSEL0 ...
MSR_ARCH_PERFMON_EVENTSEL0 + KVM_MAX_NR_PMU_GP_COUNTERS - 1:
if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
min(KVM_INTEL_PMC_MAX_GENERIC, kvm_pmu_cap.num_counters_gp))
continue;
break;
next prev parent reply other threads:[~2022-10-07 20:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-19 9:10 [PATCH v3 1/3] KVM: x86/pmu: Stop adding speculative Intel GP PMCs that don't exist yet Like Xu
2022-09-19 9:10 ` [PATCH v3 2/3] KVM: x86/pmu: Limit the maximum number of supported Intel GP counters Like Xu
2022-10-07 20:02 ` Sean Christopherson [this message]
2022-09-19 9:10 ` [PATCH v3 3/3] KVM: x86/pmu: Limit the maximum number of supported AMD " Like Xu
2022-11-07 18:34 ` Paolo Bonzini
2022-10-07 19:38 ` [PATCH v3 1/3] KVM: x86/pmu: Stop adding speculative Intel GP PMCs that don't exist yet Sean Christopherson
2022-10-14 8:54 ` Like Xu
2022-10-14 16:18 ` Sean Christopherson
2022-11-07 7:26 ` Like Xu
2022-11-07 18:04 ` Paolo Bonzini
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=Y0CF3F/pJOBnY1Xz@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.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 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.