All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
Cc: kvm@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Radim Krcmar <rkrcmar@redhat.com>,
	Len Brown <len.brown@intel.com>, Kyle Huey <me@kylehuey.com>,
	Kan Liang <Kan.liang@intel.com>,
	Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH v2 3/4] Add support for AMD Core Perf Extension in guest
Date: Thu, 9 Nov 2017 19:34:25 +0100	[thread overview]
Message-ID: <20171109183425.rhqc5wrltznt5tcf@pd.tnic> (raw)
In-Reply-To: <5113a9d6e76d2c6050c1fba4007068340321521c.1509985085.git.Janakarajan.Natarajan@amd.com>


> Subject: Re: [PATCH v2 3/4] Add support for AMD Core Perf Extension in guest

Btw, your subjects need a prefix:

"x86/kvm: Add guest support for the AMD core performance counters"

for example.

On Mon, Nov 06, 2017 at 11:44:25AM -0600, Janakarajan Natarajan wrote:
> This patch adds support for AMD Core Performance counters in the guest.

Never say "This patch" in the commit message of a patch. It is
tautologically useless.

> The base event select and counter MSRs are changed. In addition, with
> the core extension, there are 2 extra counters available for performance
> measurements for a total of 6.
> 
> With the new MSRs, the logic to map them to the gp_counters[] is changed.
> New functions are introduced to get the right base MSRs and to check the
> validity of the get/set MSRs.
> 
> If the guest has vcpus of either family 16h or a generation < 15h, it

You're only talking about families here, the "generation" thing is
confusing.

> falls back to using K7 MSRs and the number of counters the guest can
> access is set to 4.
> 
> Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
> ---
>  arch/x86/kvm/pmu_amd.c | 133 +++++++++++++++++++++++++++++++++++++++++++------
>  arch/x86/kvm/x86.c     |   1 +
>  2 files changed, 120 insertions(+), 14 deletions(-)

...

> +static inline struct kvm_pmc *get_gp_pmc_amd(struct kvm_pmu *pmu, u32 msr,
> +					     enum pmu_type type)
> +{
> +	unsigned int base = get_msr_base(pmu, type);
> +
> +	if (base == MSR_F15H_PERF_CTL) {
> +		switch (msr) {
> +		case MSR_F15H_PERF_CTL0:
> +		case MSR_F15H_PERF_CTL1:
> +		case MSR_F15H_PERF_CTL2:
> +		case MSR_F15H_PERF_CTL3:
> +		case MSR_F15H_PERF_CTL4:
> +		case MSR_F15H_PERF_CTL5:
> +			/*
> +			 * AMD Perf Extension MSRs are not continuous.
> +			 *
> +			 * E.g. MSR_F15H_PERF_CTR0 -> 0xc0010201
> +			 *	MSR_F15H_PERF_CTR1 -> 0xc0010203
> +			 *
> +			 * These are mapped to work with gp_counters[].
> +			 * The index into the array is calculated by
> +			 * dividing the difference between the requested
> +			 * msr and the msr base by 2.
> +			 *
> +			 * E.g. MSR_F15H_PERF_CTR1 uses
> +			 *	->gp_counters[(0xc0010203-0xc0010201)/2]
> +			 *	->gp_counters[1]
> +			 */
> +			return &pmu->gp_counters[(msr - base) >> 1];

Ok, it took me a bit of staring to understand what you're doing here.
And frankly, this scheme is silly and fragile. You're relying on the
fact that you can do math with the MSR numbers to get you the GP counter
number. The moment that changes in future families, you are going to
have to devise a new scheme for the new family.

And instead of doing that, you're much better off producing a simple
MSR -> counter mapping for each family which is a simple switch-case.
No need to do get_msr_base() and whatnot - you simply feed in the MSR
number and the function spits out a gp_counters index. You only need to
check the family of the vcpu.

Then lookers will be able to understand the code at a quick glance too.

...

> @@ -153,8 +251,15 @@ static int amd_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  static void amd_pmu_refresh(struct kvm_vcpu *vcpu)
>  {
>  	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
> +	int family, nr_counters;
> +
> +	family = guest_cpuid_family(vcpu);
> +	if (family == 0x15 || family == 0x17)
> +		nr_counters = AMD64_NUM_COUNTERS_CORE;
> +	else
> +		nr_counters = AMD64_NUM_COUNTERS;
>  
> -	pmu->nr_arch_gp_counters = AMD64_NUM_COUNTERS;
> +	pmu->nr_arch_gp_counters = nr_counters;
>  	pmu->counter_bitmask[KVM_PMC_GP] = ((u64)1 << 48) - 1;
>  	pmu->reserved_bits = 0xffffffff00200000ull;
>  	/* not applicable to AMD; but clean them to prevent any fall out */
> @@ -169,7 +274,7 @@ static void amd_pmu_init(struct kvm_vcpu *vcpu)
>  	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
>  	int i;
>  
> -	for (i = 0; i < AMD64_NUM_COUNTERS ; i++) {
> +	for (i = 0; i < AMD64_NUM_COUNTERS_CORE ; i++) {

This all works because INTEL_PMC_MAX_GENERIC is bigger than the AMD num
counters but you need to check all that.

Also, the finding out of the nr_counters you do in amd_pmu_refresh()
should happen here, in the init function so that you have
pmu->nr_arch_gp_counters properly set and then when you iterate over
counters in the remaining functions, you do:

	for (i = 0; i < pmu->nr_arch_gp_counters ; i++) {

instead of using those defines which are not always correct, depending
on the family.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

  reply	other threads:[~2017-11-09 18:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-06 17:44 [PATCH v2 0/4] Support Perf Extension on AMD KVM guests Janakarajan Natarajan
2017-11-06 17:44 ` [PATCH v2 1/4] x86/kvm/cpuid: Fix CPUID function for word 6 (80000001_ECX) Janakarajan Natarajan
2017-11-06 18:09   ` Jim Mattson
2017-11-06 18:14   ` Krish Sadhukhan
2017-11-06 20:38   ` Janakarajan Natarajan
2017-11-10 21:47     ` Radim Krcmar
2017-11-06 17:44 ` [PATCH v2 2/4] Add AMD Core Perf Extension MSRs Janakarajan Natarajan
2017-11-09 18:00   ` Borislav Petkov
2017-11-06 17:44 ` [PATCH v2 3/4] Add support for AMD Core Perf Extension in guest Janakarajan Natarajan
2017-11-09 18:34   ` Borislav Petkov [this message]
2017-11-15 19:04     ` Natarajan, Janakarajan
2017-11-15 19:07       ` Borislav Petkov
2017-11-16 17:13         ` Natarajan, Janakarajan
2017-11-16 17:25           ` Borislav Petkov
2017-11-16 18:00             ` Natarajan, Janakarajan
2017-11-17 11:44               ` Borislav Petkov
2017-11-27 18:21                 ` Natarajan, Janakarajan
2017-12-01 19:30                 ` Natarajan, Janakarajan
2017-12-05 17:56                   ` Radim Krcmar
2017-12-06 20:19                     ` Natarajan, Janakarajan
2017-11-06 17:44 ` [PATCH v2 4/4] Expose AMD Core Perf Extension flag to guests Janakarajan Natarajan

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=20171109183425.rhqc5wrltznt5tcf@pd.tnic \
    --to=bp@suse.de \
    --cc=Janakarajan.Natarajan@amd.com \
    --cc=Kan.liang@intel.com \
    --cc=grzegorz.andrejczuk@intel.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@kylehuey.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /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.