Re: [PATCH v2] hw/i386: disable smbus migration for xenfv

From: Olaf Hering <olaf@aepfle.de>
To: Paul Durrant <pdurrant@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"open list:All patches CC here" <qemu-devel@nongnu.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Date: Mon, 27 Jan 2020 10:09:51 +0100	[thread overview]
Message-ID: <20200127100951.0803d167.olaf@aepfle.de> (raw)
In-Reply-To: <CACCGGhCO_OqPq__t+V9RrFMYhXCJ5N4PPkq9CASJULV2rTkT-g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]

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 --]
