public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wei Wang <wei.w.wang@intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"kvm list" <kvm@vger.kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Andi Kleen" <ak@linux.intel.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Kan Liang" <kan.liang@intel.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	like.xu@intel.com, "Jann Horn" <jannh@google.com>,
	arei.gonglei@huawei.com
Subject: Re: [PATCH v4 04/10] KVM/x86: intel_pmu_lbr_enable
Date: Fri, 04 Jan 2019 18:09:17 +0800	[thread overview]
Message-ID: <5C2F30CD.6010108@intel.com> (raw)
In-Reply-To: <CALMp9eR0rkF-DuOWyB16q5r8y9DrefsMd1h4GfDkA8nmpWjMEg@mail.gmail.com>

On 01/03/2019 11:34 PM, Jim Mattson wrote:
> On Wed, Jan 2, 2019 at 11:16 PM Wei Wang <wei.w.wang@intel.com> wrote:
>> On 01/03/2019 07:26 AM, Jim Mattson wrote:
>>> On Wed, Dec 26, 2018 at 2:01 AM Wei Wang <wei.w.wang@intel.com> wrote:
>>>> The lbr stack is architecturally specific, for example, SKX has 32 lbr
>>>> stack entries while HSW has 16 entries, so a HSW guest running on a SKX
>>>> machine may not get accurate perf results. Currently, we forbid the
>>>> guest lbr enabling when the guest and host see different lbr stack
>>>> entries.
>>> How do you handle live migration?
>> This feature is gated by the QEMU "lbr=true" option.
>> So if the lbr fails to work on the destination machine,
>> the destination side QEMU wouldn't be able to boot,
>> and migration will not happen.
> Yes, but then what happens?
>
> Fast forward to, say, 2021. You're decommissioning all Broadwell
> servers in your data center. You have to migrate the running VMs off
> of those Broadwell systems onto newer hardware. But, with the current
> implementation, the migration cannot happen. So, what do you do? I
> suppose you just never enable the feature in the first place. Right?

I'm not sure if that's the way people would do with their data centers.
What would be the point of decommissioning all the BDW machines when
there are important BDW VMs running?

The "lbr=true" option can also be disabled via QMP, which will disable the
kvm side lbr support. So if you really want to deal with the above case,
you could first disable the lbr feature on the source side, and then 
boot the
destination side QEMU without "lbr=true". The lbr feature will not be 
available
to use by the guest at the time you decide to migrate the guest to a
non-compatible physical machine.

The point of this patch is: If we couldn't offer our users accurate
lbr results, we'd better to have the feature disabled rather than
offering wrong results to confuse them.


Best,
Wei

  parent reply	other threads:[~2019-01-04 10:03 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
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 [this message]
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=5C2F30CD.6010108@intel.com \
    --to=wei.w.wang@intel.com \
    --cc=ak@linux.intel.com \
    --cc=arei.gonglei@huawei.com \
    --cc=jannh@google.com \
    --cc=jmattson@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 \
    /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