qemu-devel
[Top][All Lists]
Advanced

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

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


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH] Migration compatibility for serial
Date: Wed, 17 Jun 2015 11:26:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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



reply via email to

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