All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Greg Kurz <gkurz@linux.vnet.ibm.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-ppc@nongnu.org, Amit Shah <amit.shah@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH v3 0/2] Fix migration of old pseries
Date: Tue, 23 Feb 2016 09:31:10 +0100	[thread overview]
Message-ID: <87ziurakvl.fsf@emacs.mitica> (raw)
In-Reply-To: <20160219085944.281f4a73@bahia.huguette.org> (Greg Kurz's message of "Fri, 19 Feb 2016 08:59:44 +0100")

Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> On Fri, 19 Feb 2016 11:11:47 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
>> On Thu, Feb 18, 2016 at 12:32:11PM +0100, Greg Kurz wrote:
>> > QEMU 2.4 broke the migration of old pseries machine with the addition
>> > of configuration sections, which are sent unconditionally.
>> > 
>> > We assume that QEMU 2.3 is more deployed than any newer release (based on
>> > the versions currently shipped by most distros). This v3 series hence
>> > reverses the logic from v2: it now fully fixes migration of old pseries
>> > from/to QEMU 2.3 and provides a manual workaround for the QEMU 2.4/2.4.1/2.5
>> > case.
>> > 
>> > With this series, I could migrate the same pseries-2.3 instance in a full
>> > 2.3->2.6->2.5->2.6->2.4->2.6->2.3 cycle.  
>> 
>> Sorry, I've lost track slightly here.  Does this series apply on top
>> of, or instead of your earlier series that peeks for the config
>> section?
>> 
>
> This v3 series applies instead of the v2 that peeks for the config section.
>
> It was suggested by Laurent during review, and motivated by your decision
> to favor fixing 2.3 over 2.4.
>
> As shown in Laurent's detailed test report, migration from/to 2.3.x now works
> out of the box and 2.4.x/2.5 requires qom-set.
>
> I was also feeling a bit uncomfortable with all these machine properties to
> disable the configuration section, which was explicitly coded to be non-optional
> according to the changelog of commit 61964c23. The logic inversion in v3 seem
> to be friendlier with the configuration section design.
>
> Juan, could you share your thoughts ?

As said previously, we don't have any better fix.  We could try to make
the "enforce" thing only for some machine types, but I guess that it
would make the mess even bigger :-(

And on an unrelated topic, I guess we need to "agree" in a way to add
new features to migration for all machine types.  Right now we have:
- two x86 boards
- now s390
- and now ppc
- and I guess arm is on the way

So, I guess we would need something like of what we have on
hw/i386/pc_piix.c


static void pc_compat_2_3(MachineState *machine)
{
    PCMachineState *pcms = PC_MACHINE(machine);
    savevm_skip_section_footers();
    if (kvm_enabled()) {
        pcms->smm = ON_OFF_AUTO_OFF;
    }
    global_state_set_optional();
    savevm_skip_configuration();
}


Really, we need something like this

static void migration_compat_2_3(MachineState *machine)
{
    savevm_skip_section_footers();
    global_state_set_optional();
    savevm_skip_configuration();
}

to be included in every machine that cares about migration.  Is there
ane easy way/place where to do this globaly?

Later, Juan.

  parent reply	other threads:[~2016-02-23  8:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-18 11:32 [Qemu-devel] [PATCH v3 0/2] Fix migration of old pseries Greg Kurz
2016-02-18 11:32 ` [Qemu-devel] [PATCH v3 1/2] spapr: skip configuration section during migration of older machines Greg Kurz
2016-02-18 19:57   ` Laurent Vivier
2016-02-23  8:23   ` Juan Quintela
2016-02-18 11:32 ` [Qemu-devel] [PATCH v3 2/2] migration: allow machine to enforce configuration section migration Greg Kurz
2016-02-18 19:57   ` Laurent Vivier
2016-02-23  8:24   ` Juan Quintela
2016-02-18 20:00 ` [Qemu-devel] [PATCH v3 0/2] Fix migration of old pseries Laurent Vivier
2016-02-19  6:42   ` Greg Kurz
2016-02-19  0:11 ` David Gibson
2016-02-19  7:59   ` Greg Kurz
2016-02-22  1:09     ` David Gibson
2016-02-26 10:49       ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2016-02-26 11:03         ` David Gibson
2016-02-23  8:31     ` Juan Quintela [this message]
2016-02-23 10:01       ` [Qemu-devel] " Greg Kurz
2016-02-23 12:27         ` Greg Kurz
2016-02-19 14:41 ` Laurent Vivier
2016-02-19 16:27   ` Greg Kurz
2016-02-23 15:04     ` Greg Kurz

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=87ziurakvl.fsf@emacs.mitica \
    --to=quintela@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgilbert@redhat.com \
    --cc=gkurz@linux.vnet.ibm.com \
    --cc=lvivier@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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.