All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: amit.shah@redhat.com, Paolo Bonzini <pbonzini@redhat.com>,
	"Dr. David Alan Gilbert (git)" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Migration compatibility for serial
Date: Wed, 17 Jun 2015 11:26:07 +0200	[thread overview]
Message-ID: <877fr27kk0.fsf@neno.neno> (raw)
In-Reply-To: <20150617094829-mutt-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Wed, 17 Jun 2015 09:52:55 +0200")

"Michael S. Tsirkin" <mst@redhat.com> 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" <dgilbert@redhat.com>
>> > 
>> > 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 <dgilbert@redhat.com>
>> 
>> 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.

  parent reply	other threads:[~2015-06-17  9:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16 18:54 [Qemu-devel] [PATCH] Migration compatibility for serial Dr. David Alan Gilbert (git)
2015-06-16 20:49 ` Michael S. Tsirkin
2015-06-17  9:09   ` Dr. David Alan Gilbert
2015-06-17  6:52 ` Markus Armbruster
2015-06-17  6:58   ` Michael S. Tsirkin
2015-06-17  7:11     ` Markus Armbruster
2015-06-17  7:25       ` Michael S. Tsirkin
2015-06-17  7:41 ` Paolo Bonzini
2015-06-17  7:52   ` Michael S. Tsirkin
2015-06-17  8:11     ` Paolo Bonzini
2015-06-17 10:13       ` Michael S. Tsirkin
2015-06-17 10:48         ` Juan Quintela
2015-06-17 10:51           ` Dr. David Alan Gilbert
2015-06-17 10:56             ` Michael S. Tsirkin
2015-06-17 10:59               ` Dr. David Alan Gilbert
2015-06-17 11:36                 ` Michael S. Tsirkin
2015-06-17 10:55           ` Michael S. Tsirkin
2015-06-17 11:33         ` Paolo Bonzini
2015-06-17 11:40           ` Dr. David Alan Gilbert
2015-06-17 11:44             ` Paolo Bonzini
2015-06-17 11:48               ` Michael S. Tsirkin
2015-06-17 12:07               ` Dr. David Alan Gilbert
2015-06-17 12:20                 ` Paolo Bonzini
2015-06-17 14:44                   ` Michael S. Tsirkin
2015-06-17 16:34                     ` Juan Quintela
2015-06-17 16:39                       ` Michael S. Tsirkin
2015-06-17 16:40                         ` Paolo Bonzini
2015-06-17 11:45           ` Michael S. Tsirkin
2015-06-17 11:53             ` Paolo Bonzini
2015-06-17 11:54               ` Michael S. Tsirkin
2015-06-17 11:55                 ` Paolo Bonzini
2015-06-17 11:58                   ` Michael S. Tsirkin
2015-06-17 12:20                     ` Paolo Bonzini
2015-06-17 14:50                       ` Michael S. Tsirkin
2015-06-17 16:16                         ` Paolo Bonzini
2015-06-17 16:34                           ` Michael S. Tsirkin
2015-06-17 16:35                             ` Paolo Bonzini
2015-06-17  9:26     ` Juan Quintela [this message]
2015-06-17 10:37       ` Michael S. Tsirkin
2015-06-17  8:37   ` Dr. David Alan Gilbert
2015-06-17  8:49     ` Paolo Bonzini
2015-06-17  9:38       ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877fr27kk0.fsf@neno.neno \
    --to=quintela@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.