From: Haozhong Zhang <haozhong.zhang@intel.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, Richard Henderson <rth@twiddle.net>,
"Michael S . Tsirkin" <mst@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kvm@vger.kernel.org, Boris Petkov <bp@suse.de>,
Tony Luck <tony.luck@intel.com>,
Andi Kleen <andi.kleen@intel.com>,
rkrcmar@redhat.com, Ashok Raj <ashok.raj@intel.com>
Subject: Re: [Qemu-devel] [PATCH v4 2/3] target-i386: add migration support for Intel LMCE
Date: Mon, 20 Jun 2016 10:11:36 +0800 [thread overview]
Message-ID: <20160620021136.mepymwylqvzsku55@hz-desktop> (raw)
In-Reply-To: <20160617172016.GK18662@thinpad.lan.raisama.net>
On 06/17/16 14:20, Eduardo Habkost wrote:
> On Fri, Jun 17, 2016 at 10:01:05AM +0800, Haozhong Zhang wrote:
> > On 06/16/16 14:58, Eduardo Habkost wrote:
> > > On Thu, Jun 16, 2016 at 07:40:20PM +0200, Paolo Bonzini wrote:
> > > >
> > > >
> > > > On 16/06/2016 19:36, Eduardo Habkost wrote:
> > > > >> >
> > > > >> > Eduardo said nice for this part in previous version [1], so we may wait
> > > > >> > for his comments?
> > > > >> >
> > > > >> > [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg01992.html
> > > > > I agree we don't need this check, but I still believe it is a
> > > > > nice thing to have.
> > > > >
> > > > > In addition to detecting user errors, they don't hurt and are
> > > > > useful for things like "-cpu host", that don't guarantee
> > > > > live-migration compatibility but still allow migration if you
> > > > > ensure host capabilities are the same on both sides.
> > > >
> > > > On the other hand we don't check for this on any other property, either
> > > > CPU or device, do we? Considering "lmce=on" always breaks on an old
> > > > kernel (i.e. there's no need for an explicit ",enforce" on the -cpu
> > > > flag), I think it's unnecessary and makes things inconsistent.
> > >
> > > We don't check that because we normally can't: we usually don't
> > > send any configuration data (or anything that could be used to
> > > detect configuration mismatches) to the destination. When we do,
> > > it's often by accident.
> > >
> > > In this case, it looks like we never needed to send mcg_cap in
> > > the migration stream. But we already send it, so let's use it for
> > > something useful.
> > >
> > > I believe we should have more checks like these, when possible. I
> > > have been planning for a while to send CPUID data in the
> > > migration stream, to detect migration compatibility errors
> > > (either user errors or QEMU bugs).
> > >
> > > In theory, those checks should never be necessary. In practice I
> > > believe they would be very useful.
> > >
> >
> > Hi Eduardo and Paolo,
> >
> > What will be the conclusion? Do we still need this check?
> >
> > I'm fine to remove this check if we normally didn't make such kind of
> > checks and require users to avoid configuration mismatch.
>
> I don't know yet if Paolo is convinced that the check is still
> useful. :)
>
> I suggest doing it as a separate patch, so we can apply the rest
> of the series now and discuss/apply the check later.
>
Yes, I'll move the check to a separate patch so that we can easily
drop it if not necessary. Thanks for the suggestion!
> >
> > > >
> > > > > (I was going to suggest enabling lmce automatically on "-cpu
> > > > > host" as a follow-up patch, BTW.)
> > > >
> > > > Interesting. Technically it comes from the host kernel, not from the
> > > > host CPU. But it does sounds like a good idea; -cpu host pretty much
> > > > implies the same kernel (in addition to the same processor) on both
> > > > sides of the migration.
> > >
> > > "-cpu host" already means "whatever is allowed by the host [CPU
> > > and/or kernel]", not just "host CPU". It enables x2apic on all
> > > hosts, for example.
> > >
> >
> > Does that mean we can automatically enable LMCE for "-cpu host"?
>
> We can automatically enable LMCE for "-cpu host" if and only if
> the host kernel supports LMCE.
>
According to our discussion for KVM Patch 3, we may have to disable it
by default by -cpu host, so that pc-2.7 will not require new kernels
unless LMCE is required explicitly by users.
Thanks,
Haozhong
next prev parent reply other threads:[~2016-06-20 2:11 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 6:06 [Qemu-devel] [PATCH v4 0/3] Add QEMU support for Intel local MCE Haozhong Zhang
2016-06-16 6:06 ` [Qemu-devel] [PATCH v4 1/3] target-i386: KVM: add basic Intel LMCE support Haozhong Zhang
2016-06-16 9:50 ` Paolo Bonzini
2016-06-16 10:16 ` Haozhong Zhang
2016-06-16 10:23 ` Paolo Bonzini
2016-06-16 10:34 ` Haozhong Zhang
2016-06-16 10:42 ` Paolo Bonzini
2016-06-16 18:05 ` Eduardo Habkost
2016-06-16 18:17 ` Paolo Bonzini
2016-06-16 19:37 ` Eduardo Habkost
2016-06-17 1:26 ` Haozhong Zhang
2016-06-17 16:20 ` Eduardo Habkost
2016-06-20 2:04 ` Haozhong Zhang
2016-06-16 6:06 ` [Qemu-devel] [PATCH v4 2/3] target-i386: add migration support for Intel LMCE Haozhong Zhang
2016-06-16 9:51 ` Paolo Bonzini
2016-06-16 10:29 ` Haozhong Zhang
2016-06-16 10:41 ` Paolo Bonzini
2016-06-16 10:55 ` Haozhong Zhang
2016-06-16 17:36 ` Eduardo Habkost
2016-06-16 17:40 ` Paolo Bonzini
2016-06-16 17:58 ` Eduardo Habkost
2016-06-17 2:01 ` Haozhong Zhang
2016-06-17 17:20 ` Eduardo Habkost
2016-06-17 17:26 ` Paolo Bonzini
2016-06-20 2:11 ` Haozhong Zhang [this message]
2016-06-20 6:58 ` Paolo Bonzini
2016-06-20 7:26 ` Haozhong Zhang
2016-06-16 19:53 ` Eduardo Habkost
2016-06-16 6:06 ` [Qemu-devel] [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg Haozhong Zhang
2016-06-16 9:52 ` Paolo Bonzini
2016-06-16 11:19 ` Haozhong Zhang
2016-06-17 17:31 ` Laszlo Ersek
2016-06-17 20:21 ` Raj, Ashok
2016-06-17 20:48 ` Laszlo Ersek
2016-06-17 20:55 ` Raj, Ashok
2016-06-17 21:30 ` Laszlo Ersek
2016-06-20 3:09 ` Haozhong Zhang
2016-06-20 6:56 ` Paolo Bonzini
2016-06-20 7:20 ` Haozhong Zhang
2016-06-22 10:18 ` Haozhong Zhang
2016-06-22 15:51 ` Laszlo Ersek
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=20160620021136.mepymwylqvzsku55@hz-desktop \
--to=haozhong.zhang@intel.com \
--cc=andi.kleen@intel.com \
--cc=ashok.raj@intel.com \
--cc=bp@suse.de \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkrcmar@redhat.com \
--cc=rth@twiddle.net \
--cc=tony.luck@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;
as well as URLs for NNTP newsgroup(s).