All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Natarajan, Janakarajan" <Janakarajan.Natarajan@amd.com>
To: Radim Krcmar <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>, Paolo Bonzini <pbonzini@redhat.com>,
	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>,
	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: Wed, 6 Dec 2017 14:19:11 -0600	[thread overview]
Message-ID: <3e3cfa15-8a92-56e4-008e-4d4734efce21@amd.com> (raw)
In-Reply-To: <20171205175604.GA20099@flask>

On 12/5/2017 11:56 AM, Radim Krcmar wrote:
> 2017-12-01 13:30-0600, Natarajan, Janakarajan:
>> On 11/17/2017 5:44 AM, Borislav Petkov wrote:
>>> On Thu, Nov 16, 2017 at 12:00:11PM -0600, Natarajan, Janakarajan wrote:
>>>> Ah my apologies. So when the pmu is initialized the cpuid entries
>>>> aren't available then.
>>> So let's see:
>>>
>>> ... kvm_arch_vcpu_create() ->
>>> svm_create_vcpu() ->
>>> kvm_vcpu_init() ->
>>> kvm_arch_vcpu_init() ->
>>>
>>> <--- HERE
>>>
>>> kvm_pmu_init()
>>>
>>> But at HERE in kvm_arch_vcpu_init() right before kvm_pmu_init() we do already query
>>> cpuid:
>>>
>>> 	vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
>>>
>>> so it's not like we don't know about cpuid leafs at that point. Which
>>> would mean that the code can be made to set the CPU family earlier,
>>> before kvm_pmu_init() runs so that you have the proper CPU family and
>>> thus have this thing properly designed.
>>>
>>> Maybe Paolo and Radim have a better suggestion here...
>> Paolo, Radim any suggestions about this. I feel that the number of counters
>> initialized can be 6
> This is the best solution with the current framework.

Okay.

>
>> and the subsequent code (kvm_pmu_refresh()) takes care of the number of
>> counters to be used (4 or 6)
>> based on the vcpu family.
> Can't we look only at X86_FEATURE_PERFCTR_CORE and completely ignore the
> AMD family?
> Using the family would bring problems with compatiblity.

Yeah. We can just use the X86_FEATURE_PERFCTR_CORE flag as a check. I'll 
send a v3
with the changes.

Thanks.

>
> Thanks.

  reply	other threads:[~2017-12-06 20:19 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
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 [this message]
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=3e3cfa15-8a92-56e4-008e-4d4734efce21@amd.com \
    --to=janakarajan.natarajan@amd.com \
    --cc=Kan.liang@intel.com \
    --cc=bp@suse.de \
    --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.