qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Olaf Hering <olaf@aepfle.de>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	Paul Durrant <paul@xen.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Richard Henderson <rth@twiddle.net>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"open list:All patches CC here" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Date: Thu, 16 Jan 2020 19:26:39 +0100	[thread overview]
Message-ID: <0335edd2-3d33-88f8-2ab4-4791f7289885@redhat.com> (raw)
In-Reply-To: <20200116180321.24968-1-olaf@aepfle.de>

On 16/01/20 19:03, Olaf Hering wrote:
> With commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea a new member
> smbus_no_migration_support was added, and enabled in two places.
> With commit 4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi
> got new elements, which are conditionally filled. As a result, an
> incoming migration expected smbus related data unless smbus migration
> was disabled for a given MachineClass.
> 
> Since commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea forgot to handle
> xenfv, live migration to receiving hosts using qemu-4.0 and later is broken.
> 
> Therefore this patch must be applied to stable-4.x as well.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> ---
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index fa12203079..e19716d0d3 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -952,6 +952,7 @@ static void xenfv_machine_options(MachineClass *m)
>      m->desc = "Xen Fully-virtualized PC";
>      m->max_cpus = HVM_MAX_VCPUS;
>      m->default_machine_opts = "accel=xen";
> +    m->smbus_no_migration_support = true;
>  }
>  
>  DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init,
> 

This patch is wrong; xenfv does not support cross-version migration
compatibility.  Even if the migration stream does not change, the
hardware exposed to the guest will.

My understanding is that Xen is able to use "-M
pc-i440fx-VERSION,accel=xen".  The presence of the version in the
machine type guarantees that the migration stream is compatible and that
the hardware exposed to the guest is the same on the source and destination.

Is this incorrect?

Paolo



  reply	other threads:[~2020-01-16 18:28 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 17:45 [PATCH v1] hw/i386: disable smbus migration for xenpv Olaf Hering
2020-01-13 17:46 ` [PATCH v1] hw/i386: disable smbus migration for xenfv Olaf Hering
2020-01-15 13:51 ` [PATCH v1] hw/i386: disable smbus migration for xenpv Michael S. Tsirkin
2020-01-16 18:03 ` [PATCH v2] hw/i386: disable smbus migration for xenfv Olaf Hering
2020-01-16 18:26   ` Paolo Bonzini [this message]
2020-01-16 18:33     ` Olaf Hering
2020-01-16 18:50       ` Paolo Bonzini
2020-01-17  9:22     ` Olaf Hering
2020-01-17 10:27       ` Paolo Bonzini
2020-01-17 13:06         ` Olaf Hering
2020-01-20 11:18           ` Paul Durrant
2020-01-27  9:09             ` Olaf Hering
2020-02-18 17:27               ` Olaf Hering
2020-02-18 17:37                 ` Paolo Bonzini
2020-02-18 18:30                   ` Olaf Hering
2020-02-18 19:44                   ` Olaf Hering
2020-02-19  8:05                     ` Paolo Bonzini
2020-02-19  8:13                       ` Olaf Hering
2020-01-27  9:35             ` Paolo Bonzini
2020-01-27 13:26               ` Olaf Hering
2020-01-27 18:21                 ` Paolo Bonzini
2020-02-19 11:35     ` Olaf Hering
2020-02-19 14:14       ` Olaf Hering
2020-02-20 10:50         ` Paolo Bonzini
2020-03-25  6:47 ` [PATCH v3] piix: fix xenfv regression, add compat machine xenfv-qemu4 Olaf Hering
2020-03-25  7:11   ` no-reply
2020-03-25  7:25   ` no-reply
2020-03-25 15:39   ` Paolo Bonzini
2020-03-25 15:45     ` Olaf Hering
2020-03-25 17:06       ` Paolo Bonzini
2020-03-27 15:19         ` Olaf Hering
2020-03-27 15:18 ` [PATCH v4] " Olaf Hering
2020-03-27 15:45   ` no-reply
2020-03-27 15:59   ` Paolo Bonzini
2020-03-28  7:09     ` Olaf Hering
2020-03-28  8:56       ` Paolo Bonzini
2020-04-06 16:00       ` Paolo Bonzini
2020-04-06 16:11         ` Olaf Hering
2020-03-27 16:01   ` no-reply

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=0335edd2-3d33-88f8-2ab4-4791f7289885@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=anthony.perard@citrix.com \
    --cc=ehabkost@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=olaf@aepfle.de \
    --cc=paul@xen.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=sstabellini@kernel.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 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).