qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: "Ryan Harper" <ryan.harper@canonical.com>,
	"Serge Hallyn" <serge.hallyn@canonical.com>,
	"quintela@redhat.com" <quintela@redhat.com>,
	Libvirt <libvir-list@redhat.com>,
	"Serge Hallyn" <serge.hallyn@ubuntu.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Alexander Graf" <agraf@suse.de>,
	"Cole Robinson" <crobinso@redhat.com>,
	"Amit Shah" <amit.shah@redhat.com>,
	"Bruce Rogers" <brogers@suse.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Date: Mon, 4 Aug 2014 18:59:11 +0200	[thread overview]
Message-ID: <20140804165911.GA22288@redhat.com> (raw)
In-Reply-To: <97E09F60-7DEF-4306-9978-6A78DA986C1A@alex.org.uk>

On Mon, Aug 04, 2014 at 05:46:58PM +0100, Alex Bligh wrote:
> Michael,
> 
> On 4 Aug 2014, at 17:22, Michael S. Tsirkin <mst@redhat.com> wrote:
> 
> >> 
> >> These are capable of modifying fields within the
> >> VMStateDescription of the relevant object.
> >> 
> >> However, the PIIX4 change modifies the minimum_version_id
> >> (outside fields); I don't quite see how that would work.
> >> Can you help here?
> > 
> > If you want to support lower version IDs,
> > you can just decrease minimum_version_id.
> > 
> > field_exists gets the version ID so you can
> > parse different fields depending on the
> > version.
> 
> The issue is that qemu-kvm 1.0 used version ID 2
> but is actually sending a version 3 structure.
> 
> I don't think I can just reduce the minimum version
> ID.



> As per the comment in the original patch from
> Cole Robinson:
> 
> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
> 
> --- a/hw/acpi/piix4.c
> +++ b/hw/acpi/piix4.c
> @@ -289,7 +289,13 @@ static int acpi_load_old(QEMUFile *f, void *opaque, int version_id)
>  static const VMStateDescription vmstate_acpi = {
>      .name = "piix4_pm",
>      .version_id = 3,
> -    .minimum_version_id = 3,
> +    /*
> +     * qemu-kvm 1.2 uses qemu.git version 3 format, but advertised as 2.
> +     * This allows incoming migration from qemu-kvm, but breaks incoming
> +     * migration from qemu < 1.3.
> +     */
> +    //minimum_version_id = 3,
> +    .minimum_version_id = 2,
>      .minimum_version_id_old = 1,
>      .load_state_old = acpi_load_old,
>      .post_load = vmstate_acpi_post_load,
> 
> An inbound migration from qemu-1.0-git, qemu-1.1 or
> qemu-1.2 will have version ID 2 and actually mean version
> 2; currently (i.e. with minimum_version_id = 3), these
> use the minimum_version_id_old field (1) and
> acpi_load_old routine.
> 
> If I decrease minimum_version_id to 2, as far as I can
> tell this will break inbound migration from the 'good'
> earlier versions, whilst fixing qemu-1.0-kvm (which uses
> version 2 to mean version 3).
> 
> So as far as I can tell, the minimum version ID needs
> to be dependent upon inbound machine type (or machine
> parameters). By the time the command line is parsed,
> these structures have already been built. That's why
> I took the approach I did, but again I'm new to this
> so may be missing something.
> 
> Or were you suggesting I introduced a
>   test_force_use_new_load_vm_state
> type field into VMStateDescription so it can dynamically
> choose not to use the load_state_old but rather to
> use the new method, irrespective of the minimum version
> mismatch?

I was merely suggesting changing acpi_load_old to
detect the new flag and parse the qemu-kvm format.


> -- 
> Alex Bligh
> 
> 
> 

  reply	other threads:[~2014-08-04 16:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-01 19:12 [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm Alex Bligh
2014-08-01 19:12 ` [Qemu-devel] [PATCH v2 1/2] " Alex Bligh
2014-08-01 19:12 ` [Qemu-devel] [PATCH v2 2/2] Add configure option --enable-pc-1-0-qemu-kvm Alex Bligh
2014-08-04 13:35   ` Michael S. Tsirkin
2014-08-04 13:31 ` [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm Michael S. Tsirkin
2014-08-04 13:51   ` Alex Bligh
2014-08-04 14:26     ` Michael S. Tsirkin
2014-08-04 16:11       ` Alex Bligh
2014-08-04 16:22         ` Michael S. Tsirkin
2014-08-04 16:46           ` Alex Bligh
2014-08-04 16:59             ` Michael S. Tsirkin [this message]
2014-08-04 17:08               ` Alex Bligh
2014-08-04 17:16                 ` Michael S. Tsirkin
2014-08-04 15:07 ` Serge Hallyn
2014-08-07  2:50 ` Serge Hallyn
2014-08-07  5:58   ` Alex Bligh
2014-08-07 12:56     ` Serge E. Hallyn
2014-08-07 19:26     ` Serge E. Hallyn
2014-08-08  7:23       ` Alex Bligh
2014-08-08 20:28         ` Serge E. Hallyn

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=20140804165911.GA22288@redhat.com \
    --to=mst@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=alex@alex.org.uk \
    --cc=amit.shah@redhat.com \
    --cc=brogers@suse.com \
    --cc=crobinso@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=ryan.harper@canonical.com \
    --cc=serge.hallyn@canonical.com \
    --cc=serge.hallyn@ubuntu.com \
    --cc=serge@hallyn.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).