public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Wei Wang <wei.w.wang@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, mst@redhat.com, rkrcmar@redhat.com,
	ak@linux.intel.com, mingo@redhat.com
Subject: Re: [PATCH v1 4/4] KVM/vmx: enable lbr for the guest
Date: Mon, 25 Sep 2017 20:57:04 +0800	[thread overview]
Message-ID: <59C8FD20.5070109@intel.com> (raw)
In-Reply-To: <d4a81b5d-87ec-d118-112f-b017e58aa6e7@redhat.com>

On 09/25/2017 05:16 PM, Paolo Bonzini wrote:
> On 25/09/2017 06:44, Wei Wang wrote:
>> Passthrough the LBR stack to the guest, and auto switch the stack MSRs
>> upon VMEntry and VMExit.
>>
>> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> This has to be enabled separately for each guest, because it may prevent
> live migration to hosts with a different family/model.

Did you mean trapping MSR_IA32_DEBUGCTLMSR, instead of passing through it?
In that case, we would also need to modify the kernel driver (i.e. the 
PMI handler)
to check MSR_IA32_DEBUGCTLMSR before reading the LBR MSRs. Then the guest
driver can notice that the feature that is in use has been disabled 
after live
migration.

This kind of live migration disables features that are being used. Would 
it be
common in real usage to migrate between different CPU models?

I think this issue isn't specific to the LBR feature. May I know how 
would other
features be handled in this case? Thanks.

On the other hand, an alternative approach coming up to my mind is that we
can do some kind of feature negotiation at the very beginning of 
migration, and
fails live migration if the feature negotiation fails.


Best,
Wei

  reply	other threads:[~2017-09-25 12:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25  4:44 [PATCH v1 0/4] Enable LBR for the guest Wei Wang
2017-09-25  4:44 ` [PATCH v1 1/4] KVM/vmx: re-write the msr auto switch feature Wei Wang
2017-09-25 11:54   ` Paolo Bonzini
2017-09-25 13:02     ` Wei Wang
2017-09-25 14:24       ` Paolo Bonzini
2017-09-25  4:44 ` [PATCH v1 2/4] KVM/vmx: auto switch MSR_IA32_DEBUGCTLMSR Wei Wang
2017-09-25 11:57   ` Paolo Bonzini
2017-09-25  4:44 ` [PATCH v1 3/4] perf/x86: add a function to get the lbr stack Wei Wang
2017-09-25  4:44 ` [PATCH v1 4/4] KVM/vmx: enable lbr for the guest Wei Wang
2017-09-25  9:16   ` Paolo Bonzini
2017-09-25 12:57     ` Wei Wang [this message]
2017-09-25 14:57   ` Andi Kleen
2017-09-26  8:56     ` Wei Wang
2017-09-26 16:41       ` Andi Kleen
2017-09-27  1:27         ` Wei Wang
2017-09-25 14:59 ` [PATCH v1 0/4] Enable LBR " Andi Kleen
2017-09-26  8:47   ` Wei Wang
2017-09-26 16:51     ` Andi Kleen

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=59C8FD20.5070109@intel.com \
    --to=wei.w.wang@intel.com \
    --cc=ak@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=virtualization@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox