public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Wei Wang <wei.w.wang@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: Fri, 4 Jan 2019 10:57:24 -0500	[thread overview]
Message-ID: <4e5cd929-8a28-461d-7f8f-79a2f9301b7c@linux.intel.com> (raw)
In-Reply-To: <5C2F2E3E.7020306@intel.com>



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.

You may also need to introduce another new function to check if the LBR 
is compatible with guest in lbr.c, e.g. bool 
is_lbr_compatible_with_guest(int model).

bool is_lbr_compatible_with_guest(int model) {
	struct x86_pmu fake_x86_pmu;

	if (boot_cpu_data.x86_model == model)
		return true;

	__intel_pmu_init(model, &fake_x86_pmu);

	if ((x86_pmu.lbr_nr == fake_x86_pmu.lbr_nr) &&
	    (x86_pmu.lbr_tos == fake_x86_pmu.lbr_tos) &&
	    (x86_pmu.lbr_from == fake_x86_pmu.lbr_from))
		return true;

	return false;
}

> 
>> 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"?

Thanks,
Kan

  reply	other threads:[~2019-01-04 15:57 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 [this message]
2019-01-05 10:09         ` Wei Wang
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=4e5cd929-8a28-461d-7f8f-79a2f9301b7c@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=arei.gonglei@huawei.com \
    --cc=jannh@google.com \
    --cc=kan.liang@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 \
    --cc=wei.w.wang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox