[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 2/3] target-i386: add migration support for I

From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v4 2/3] target-i386: add migration support for Intel LMCE
Date: Thu, 16 Jun 2016 14:58:22 -0300
User-agent: Mutt/1.6.1 (2016-04-27)

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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]