public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wei Wang <wei.w.wang@intel.com>
To: "Liang, Kan" <kan.liang@linux.intel.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	pbonzini@redhat.com, ak@linux.intel.com, peterz@infradead.org
Cc: kan.liang@intel.com, mingo@redhat.com, rkrcmar@redhat.com,
	like.xu@intel.com, jannh@google.com, arei.gonglei@huawei.com
Subject: Re: [PATCH v4 04/10] KVM/x86: intel_pmu_lbr_enable
Date: Sat, 05 Jan 2019 18:09:59 +0800	[thread overview]
Message-ID: <5C308277.3090005@intel.com> (raw)
In-Reply-To: <4e5cd929-8a28-461d-7f8f-79a2f9301b7c@linux.intel.com>

On 01/04/2019 11:57 PM, Liang, Kan wrote:
>
>
> On 1/4/2019 4:58 AM, Wei Wang wrote:
>> On 01/03/2019 12:33 AM, Liang, Kan wrote:
>>>
>>>
>>> On 12/26/2018 4:25 AM, Wei Wang wrote:
>>>> +
>>>> +    /*
>>>> +     * It could be possible that people have vcpus of old model 
>>>> run on
>>>> +     * physcal cpus of newer model, for example a BDW guest on a SKX
>>>> +     * machine (but not possible to be the other way around).
>>>> +     * The BDW guest may not get accurate results on a SKX machine 
>>>> as it
>>>> +     * only reads 16 entries of the lbr stack while there are 32 
>>>> entries
>>>> +     * of recordings. So we currently forbid the lbr enabling when 
>>>> the
>>>> +     * vcpu and physical cpu see different lbr stack entries.
>>>
>>> I think it's not enough to only check number of entries. The LBR 
>>> from/to MSRs may be different even the number of entries is the 
>>> same, e.g SLM and KNL.
>>
>> Yes, we could add the comparison of the FROM msrs.
>>
>>>
>>>> +     */
>>>> +    switch (vcpu_model) {
>>>
>>> That's a duplicate of intel_pmu_init(). I think it's better to 
>>> factor out the common part if you want to check LBR MSRs and 
>>> entries. Then we don't need to add the same codes in two different 
>>> places when enabling new platforms.
>>>
>>
>>
>> Yes, I thought about this, but intel_pmu_init() does a lot more 
>> things in each "Case xx". Any thought about how to factor them out?
>>
>
> I think we may only move the "switch (boot_cpu_data.x86_model) { ... 
> }" to a new function, e.g. __intel_pmu_init(int model, struct x86_pmu 
> *x86_pmu)
>
> In __intel_pmu_init, if the model != boot_cpu_data.x86_model, you only 
> need to update x86_pmu.*. Just ignore global settings, e.g 
> hw_cache_event_ids, mem_attr, extra_attr etc.

Thanks for sharing. I understand the point of maintaining those models 
at one place,
but this factor-out doesn't seem very elegant to me, like below

__intel_pmu_init (int model, struct x86_pmu *x86_pmu)
{
...
switch (model)
case INTEL_FAM6_NEHALEM:
case INTEL_FAM6_NEHALEM_EP:
case INTEL_FAM6_NEHALEM_EX:
     intel_pmu_lbr_init(x86_pmu);
     if (model != boot_cpu_data.x86_model)
         return;

     /* Other a lot of things init like below..*/
     memcpy(hw_cache_event_ids, nehalem_hw_cache_event_ids,
                    sizeof(hw_cache_event_ids));
     memcpy(hw_cache_extra_regs, nehalem_hw_cache_extra_regs,
                    sizeof(hw_cache_extra_regs));
     x86_pmu.event_constraints = intel_nehalem_event_constraints;
                 x86_pmu.pebs_constraints = 
intel_nehalem_pebs_event_constraints;
                 x86_pmu.enable_all = intel_pmu_nhm_enable_all;
                 x86_pmu.extra_regs = intel_nehalem_extra_regs;
  ...

Case...
}
We need insert "if (model != boot_cpu_data.x86_model)" in every "Case xx".

What would be the rationale that we only do lbr_init for "x86_pmu"
when model != boot_cpu_data.x86_model?
(It looks more like a workaround to factor-out the function and get what 
we want)

I would prefer having them separated as this patch for now - it is 
logically more clear to me.


>
>>
>>> Actually, I think we may just support LBR for guest if it has the 
>>> identical CPU model as host. It should be good enough for now.
>>>
>>
>> I actually tried this in the first place but it failed to work with 
>> the existing QEMU.
>> For example, when we specify "Broadwell" cpu from qemu, then qemu 
>> uses Broadwell core model,
>> but the physical machine I have is Broadwell X. This patch will 
>> support this case.
>
> I mean is it good enough if we only support "-cpu host"?
>

Not really. AFAIK, people don't use this usually. It is more common to 
specify the CPU type.

Best,
Wei



  reply	other threads:[~2019-01-05 10:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-26  9:25 [PATCH v4 00/10] Guest LBR Enabling Wei Wang
2018-12-26  9:25 ` [PATCH v4 01/10] perf/x86: fix the variable type of the LBR MSRs Wei Wang
2018-12-26  9:25 ` [PATCH v4 02/10] perf/x86: add a function to get the lbr stack Wei Wang
2018-12-26  9:25 ` [PATCH v4 03/10] KVM/x86: KVM_CAP_X86_GUEST_LBR Wei Wang
2018-12-26  9:25 ` [PATCH v4 04/10] KVM/x86: intel_pmu_lbr_enable Wei Wang
2019-01-02 16:33   ` Liang, Kan
2019-01-04  9:58     ` Wei Wang
2019-01-04 15:57       ` Liang, Kan
2019-01-05 10:09         ` Wei Wang [this message]
2019-01-07 14:22           ` Liang, Kan
2019-01-08  6:13             ` Wei Wang
2019-01-08 14:08               ` Liang, Kan
2019-01-09  1:54                 ` Wei Wang
2019-01-02 23:26   ` Jim Mattson
2019-01-03  7:22     ` Wei Wang
2019-01-03 15:34       ` Jim Mattson
2019-01-03 17:18         ` Andi Kleen
2019-01-04 10:09         ` Wei Wang
2019-01-04 15:53           ` Jim Mattson
2019-01-05 10:15             ` Wang, Wei W
2018-12-26  9:25 ` [PATCH v4 05/10] KVM/x86: expose MSR_IA32_PERF_CAPABILITIES to the guest Wei Wang
2019-01-02 23:40   ` Jim Mattson
2019-01-03  8:00     ` Wei Wang
2019-01-03 15:25       ` Jim Mattson
2019-01-07  9:15         ` Wei Wang
2019-01-07 18:05           ` Jim Mattson
2019-01-07 18:20             ` Andi Kleen
2019-01-07 18:48               ` Jim Mattson
2019-01-07 20:14                 ` Andi Kleen
2019-01-07 21:00                   ` Jim Mattson
2019-01-08  7:53                 ` Wei Wang
2019-01-08 17:19                   ` Jim Mattson
2018-12-26  9:25 ` [PATCH v4 06/10] perf/x86: no counter allocation support Wei Wang
2018-12-26  9:25 ` [PATCH v4 07/10] KVM/x86/vPMU: Add APIs to support host save/restore the guest lbr stack Wei Wang
2018-12-26  9:25 ` [PATCH v4 08/10] perf/x86: save/restore LBR_SELECT on vCPU switching Wei Wang
2018-12-26  9:25 ` [PATCH v4 09/10] perf/x86: function to check lbr user callstack mode Wei Wang
2018-12-26  9:25 ` [PATCH v4 10/10] KVM/x86/lbr: lazy save the guest lbr stack Wei Wang
2018-12-27 20:51   ` Andi Kleen
2018-12-28  3:47     ` Wei Wang
2018-12-28 19:10       ` Andi Kleen
2018-12-27 20:52   ` [PATCH v4 10/10] KVM/x86/lbr: lazy save the guest lbr stack II Andi Kleen
2018-12-29  4:25     ` Wang, Wei W

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=5C308277.3090005@intel.com \
    --to=wei.w.wang@intel.com \
    --cc=ak@linux.intel.com \
    --cc=arei.gonglei@huawei.com \
    --cc=jannh@google.com \
    --cc=kan.liang@intel.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=like.xu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rkrcmar@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