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

[Michael S. Tsirkin]

On Wed, Jun 17, 2015 at 11:26:07AM +0200, Juan Quintela wrote:
> "Michael S. Tsirkin" <address@hidden> wrote:
> > On Wed, Jun 17, 2015 at 09:41:49AM +0200, Paolo Bonzini wrote:
> >> 
> >> 
> >> On 16/06/2015 20:54, Dr. David Alan Gilbert (git) wrote:
> >> > From: "Dr. David Alan Gilbert" <address@hidden>
> >> > 
> >> > Older QEMUs dont understand the new (sub)sections that
> >> > may be generated in the serial device.   Limit their generation
> >> > to newer machine types.
> >> > 
> >> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> >> 
> >> 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.
> >> 
> >> Paolo
> >
> > 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.
> 
> It is not consistent.  It is that in 2.2 are broken.
> The case of the "broken" thing is that some users don't matter.  Think
> that you have a getty listening in a serial console.  Some users don't
> care about breaking serial console during migration because they are not
> using serial console, it just happens that for some reason, it has been
> configured.
> 
> So, the problem we have here is:
> 
> - pre 2.3: serial sometimes didn't migrate correctly
> - post 2.4: we migrate serial correctly (always)
> 
> We can get the old behaviour (that is what this series do), but that
> just mean that we _know_ that we are breaking serial during migration.
> Without this patch, we only send the serial information if we are using
> serial.
> 
> Why is this case special?  It appears that it is normal to have
> syslog/getty whatever on a serial, users didn't notice that they have it
> enabled, and now migration is not working and it used to work.
> 
> On the other hand, there are the users that were using serial, and now
> it works correctly for them.
>
> Correct thing to do: NO to apply this series.
> 
> Easier and more userfriendly thing: apply the series.
> 
> I preffer (for upstream) not applying the series, as they are incorrect.
> On the other hand, we have applied them on downstream (RHEL), so you can
> see that they are kinda useful.
> 
> You can't have both things.
> 
> As said, I preffer for upstream the "correct" behaviour, even if that is
> a bit less userfriendly.  But I can understand why (in this case mst)
> disagree on this.
> 
> Later, Juan.

I think we need to be more specific. I think that under typical use the
new sections do not appear, and migration just works.
Under stress, some info is needed that was missing in qemu 2.2.
What's the result under 2.2? I'm guessing either lost characters or
broken serial.  Our current code instead breaks migration to 2.2.

If we can make do with just losing characters, then I think
it's better than breaking migration.

OTOH if migration breaks serial completely, it is harder to decide.

Which is it?


-- 
MST