From: Olaf Hering <olaf@aepfle.de>
To: Paul Durrant <pdurrant@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Anthony Perard <anthony.perard@citrix.com>
Cc: "open list:All patches CC here" <qemu-devel@nongnu.org>,
Richard Henderson <rth@twiddle.net>,
Eduardo Habkost <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Date: Tue, 18 Feb 2020 18:27:28 +0100 [thread overview]
Message-ID: <20200218182728.4b7f17b7.olaf@aepfle.de> (raw)
In-Reply-To: <20200127100951.0803d167.olaf@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
The approach below (making 'xenfv' an alias of 'pc') does not work:
xen_enabled() is false when pc_i440fx_3_1_machine_options runs.
So, how is this incompatibility between qemu2/3 and qemu4+ supposed to be fixed?
Using '-machine pc,accel=xen -device xen-platform' is incompatible with '-machine xenpv' because the platform device has a different PCI address. As such it is not migrateable.
Olaf
Am Mon, 27 Jan 2020 10:09:51 +0100
schrieb Olaf Hering <olaf@aepfle.de>:
> Am Mon, 20 Jan 2020 11:18:41 +0000
> schrieb Paul Durrant <pdurrant@gmail.com>:
>
> > On Fri, 17 Jan 2020 at 13:06, Olaf Hering <olaf@aepfle.de> wrote:
> > > What would future domUs lose if 'xenfv' would be locked to 'pc-i440fx-3.0'?
>
> > I guess eventually that pc type would be removed and then we'd have a
> > compat issue. Ideally I think libxl should simply not use xenfv and
> > then it can be deprecated and removed, and then such issues can be
> > dealt with directly in xl/libxl.
>
> I think this does not answer the question at all.
> What future versions of libxl do is one thing.
> What existing versions of libxl do with future versions of qemu is another.
>
>
> IMO it was wrong to map "xenfv" to "pc", simply because it entirely
> ignores live migration. We were just lucky until qemu-3.1. Maybe the
> creators of 'xenfv' just meant it to be "do everything to make it
> compatible with HVM".
>
> What about a variant of this change, to lock 'xenfv' to 'qemu-3.0'?
>
>
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -490,6 +490,13 @@ static void pc_i440fx_3_0_machine_options(MachineClass *m)
> pc_i440fx_3_1_machine_options(m);
> compat_props_add(m->compat_props, hw_compat_3_0, hw_compat_3_0_len);
> compat_props_add(m->compat_props, pc_compat_3_0, pc_compat_3_0_len);
> +
> + m->alias = "xenfv";
> + if (xen_enabled()) {
> + m->desc = "Xen Fully-virtualized PC";
> + m->max_cpus = HVM_MAX_VCPUS;
> + m->default_machine_opts = "accel=xen";
> + }
> }
>
> DEFINE_I440FX_MACHINE(v3_0, "pc-i440fx-3.0", NULL,
> @@ -500,6 +507,7 @@ static void pc_i440fx_2_12_machine_options(MachineClass *m)
> pc_i440fx_3_0_machine_options(m);
> compat_props_add(m->compat_props, hw_compat_2_12, hw_compat_2_12_len);
> compat_props_add(m->compat_props, pc_compat_2_12, pc_compat_2_12_len);
> + m->alias = NULL;
> }
>
> DEFINE_I440FX_MACHINE(v2_12, "pc-i440fx-2.12", NULL,
> @@ -946,14 +954,3 @@ DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
> isapc_machine_options);
>
>
> -#ifdef CONFIG_XEN
> -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";
> -}
> -
> -DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init,
> - xenfv_machine_options);
> -#endif
>
>
> Olaf
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-02-18 17: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
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 [this message]
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=20200218182728.4b7f17b7.olaf@aepfle.de \
--to=olaf@aepfle.de \
--cc=anthony.perard@citrix.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pdurrant@gmail.com \
--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 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.