Re: [PATCH v4 2/3] target-i386: add migration support for Intel LMCE

From: Eduardo Habkost <ehabkost@redhat.com>
To: 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: [PATCH v4 2/3] target-i386: add migration support for Intel LMCE
Date: Fri, 17 Jun 2016 14:20:16 -0300	[thread overview]
Message-ID: <20160617172016.GK18662@thinpad.lan.raisama.net> (raw)
In-Reply-To: <20160617020105.mjelzxhdy5wcgqcm@hz-desktop>

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.

> 
> > > 
> > > > (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.

-- 
Eduardo