Re: [Qemu-devel] [PATCH] Migration compatibility for serial

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 17, 2015 at 11:51:57AM +0100, Dr. David Alan Gilbert wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Wed, Jun 17, 2015 at 10:11:48AM +0200, Paolo Bonzini wrote:
> > >> 
> > >> 
> > >> On 17/06/2015 09:52, Michael S. Tsirkin wrote:
> > >> > > No, please.  Upstream QEMU doesn't want to get into judgement about when
> > >> > > migration quality might be "good enough" that you can drop subsections.
> > >> > >  It's one thing to perfect the .needed functions to make the appearance
> > >> > > of subsections as unlikely as possible, but adding flags is not
> > >> > > something we've done so far---and not something at least *I* want to do.
> > >> > 
> > >> > Not like this, sure.  But e.g. patches that force specific fields to
> > >> > behave in a way consistent with QEMU 2.2, with appropriate
> > >> > doducmentation would be ok I think.
> > >> 
> > >> That's not what 2.2 means in "pc-i440fx-2.2".  It means "same hardware
> > >> as 2.2", not "bug-compatible with 2.2".
> > >> 
> > >> Refining the .needed functions (e.g. see commit bfa7362889) is just
> > >> that: describing when a subsection is needed.  Forcing specific fields
> > >> to behave in a way consistent with QEMU 2.2 is bug compatibility.
> > >> 
> > >> Paolo
> > >
> > > We do bug-compatible if it's not a big pain, too.
> > 
> > In this case, there is disagreement about what is better:
> > - correct solution
> > - bug compatible
> > 
> > We can't have both in this case :-(
> > 
> > Notice that if "both" are 2.2 <improved>, i.e. 2.3 with -M
> > pc-i440fx-2.2, we also got the correct behaviour.  So the matrix is
> > something like:
> > 
> > Source: 2.2  Destination: 2.2 -> bug compatible 2.2
> > Source: 2.3  Destination: 2.2 -> breaks if serial is being used, works otherwise
> > Source: 2.3  Destination: 2.3 with -M pc-i440fx-2.2: works always
> 
> To be fair the 2.3->2.2 is more subtle; opening it is unlikely
> to generate the subsections; it needs a bit more than that (certainly on Linux)
> figuring out exactly what triggers each subsection is trickier.
> 
> Dave

And more importantly, what is the result of skipping them,
like you proposed. E.g. if guests crash that's no
better than failing migration.

> > 
> > 
> > So the problem is 2.3 -> 2.2 when serial is being used (notice that just
> > opening it it is using).  That is what we are differing about what is
> > the right thing to do.  As Paolo says, in upstream, we have done in the
> > past the correct thing, in downstream, it depends.
> > 
> > Notice that adding this patch makes that the three cases are bug
> > compatible, i.e. there is no way to detect breakage neither a way to fix
> > the issue (fix without the patch is just upgrade both binaries.
> > )
> > 
> > Later, Juan.
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK