[Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types

[Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types

[Wei Huang]

We start to see more features been added to ARM virtual machine models.
For the purpose of backward compatibility (e.g. migration), it is time
to consider versioning machine types for ARM VMs. As a beginning step, this
patchset defines an abstract machine type for ARM VMs. The current
"virt" machine is re-written based on this new machine type accordingly.
These patches have been verified by booting existing VMs.

Note that I am seeking inputs from the community by putting RFC in the
subject line. Please let me know your opinions. I will send out V1
afterwards.

Thanks,
-Wei

Wei Huang (2):
  arm: virt: Add an abstract ARM virt machine type
  arm: virt: Move machine class init code to the abstract machine type

 hw/arm/virt.c | 60 +++++++++++++++++++++++++++++++++++++++--------------------
 1 file changed, 40 insertions(+), 20 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH RFC 1/2] arm: virt: Add an abstract ARM virt machine type

[Wei Huang]

In preparation for future ARM virt machine types, this patch creates
an abstract type for all ARM machines. The current machine type in
QEMU (i.e. "virt") is renamed to "virt-2.5", which is similar to other
architectures. For the purpose of backward compatibility, "virt" is
converted to an alias, pointing to "virt-2.5". With this patch,
"qemu -M ?" lists the following virtual machine types:

virt                 QEMU 2.5 ARM Virtual Machine (alias of virt-2.5)
virt-2.5             QEMU 2.5 ARM Virtual Machine

Signed-off-by: Wei Huang <wei@redhat.com>
---
 hw/arm/virt.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 44bbbea..ee15301 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1251,6 +1251,19 @@ static void virt_set_gic_version(Object *obj, const char *value, Error **errp)
     }
 }
 
+static void virt_machine_class_init(ObjectClass *oc, void *data)
+{
+}
+
+static const TypeInfo virt_machine_info = {
+    .name          = TYPE_VIRT_MACHINE,
+    .parent        = TYPE_MACHINE,
+    .abstract      = true,
+    .instance_size = sizeof(VirtMachineState),
+    .class_size    = sizeof(VirtMachineClass),
+    .class_init    = virt_machine_class_init,
+};
+
 static void virt_instance_init(Object *obj)
 {
     VirtMachineState *vms = VIRT_MACHINE(obj);
@@ -1288,7 +1301,9 @@ static void virt_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
 
-    mc->desc = "ARM Virtual Machine",
+    mc->desc = "QEMU 2.5 ARM Virtual Machine";
+    mc->alias = "virt";
+    mc->is_default = 1;
     mc->init = machvirt_init;
     /* Start max_cpus at the maximum QEMU supports. We'll further restrict
      * it later in machvirt_init, where we have more information about the
@@ -1302,16 +1317,15 @@ static void virt_class_init(ObjectClass *oc, void *data)
 }
 
 static const TypeInfo machvirt_info = {
-    .name = TYPE_VIRT_MACHINE,
-    .parent = TYPE_MACHINE,
-    .instance_size = sizeof(VirtMachineState),
+    .name = MACHINE_TYPE_NAME("virt-2.5"),
+    .parent = TYPE_VIRT_MACHINE,
     .instance_init = virt_instance_init,
-    .class_size = sizeof(VirtMachineClass),
     .class_init = virt_class_init,
 };
 
 static void machvirt_machine_init(void)
 {
+    type_register_static(&virt_machine_info);
     type_register_static(&machvirt_info);
 }
 
-- 
1.8.3.1

[Qemu-devel] [PATCH RFC 2/2] arm: virt: Move machine class init code to the abstract machine type

[Wei Huang]

This patch moves the common class initialization code from
"virt-2.5" to the new abstract class. An empty property is added to
"virt-2.5" machine. In the meanwhile, related machine funtion are
renamed to "virt_2_5_blah_blah" for consistency.

Signed-off-by: Wei Huang <wei@redhat.com>
---
 hw/arm/virt.c | 34 ++++++++++++++++++++--------------
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index ee15301..650dfe6 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1253,6 +1253,18 @@ static void virt_set_gic_version(Object *obj, const char *value, Error **errp)
 
 static void virt_machine_class_init(ObjectClass *oc, void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
+    mc->init = machvirt_init;
+    /* Start max_cpus at the maximum QEMU supports. We'll further restrict
+     * it later in machvirt_init, where we have more information about the
+     * configuration of the particular instance.
+     */
+    mc->max_cpus = MAX_CPUMASK_BITS;
+    mc->has_dynamic_sysbus = true;
+    mc->block_default_type = IF_VIRTIO;
+    mc->no_cdrom = 1;
+    mc->pci_allow_0_address = true;
 }
 
 static const TypeInfo virt_machine_info = {
@@ -1264,7 +1276,7 @@ static const TypeInfo virt_machine_info = {
     .class_init    = virt_machine_class_init,
 };
 
-static void virt_instance_init(Object *obj)
+static void virt_2_5_instance_init(Object *obj)
 {
     VirtMachineState *vms = VIRT_MACHINE(obj);
 
@@ -1297,30 +1309,24 @@ static void virt_instance_init(Object *obj)
                                     "Valid values are 2, 3 and host", NULL);
 }
 
-static void virt_class_init(ObjectClass *oc, void *data)
+static void virt_2_5_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
+    static GlobalProperty compat_props[] = {
+        { /* end of list */ }
+    };
 
     mc->desc = "QEMU 2.5 ARM Virtual Machine";
     mc->alias = "virt";
     mc->is_default = 1;
-    mc->init = machvirt_init;
-    /* Start max_cpus at the maximum QEMU supports. We'll further restrict
-     * it later in machvirt_init, where we have more information about the
-     * configuration of the particular instance.
-     */
-    mc->max_cpus = MAX_CPUMASK_BITS;
-    mc->has_dynamic_sysbus = true;
-    mc->block_default_type = IF_VIRTIO;
-    mc->no_cdrom = 1;
-    mc->pci_allow_0_address = true;
+    mc->compat_props = compat_props;
 }
 
 static const TypeInfo machvirt_info = {
     .name = MACHINE_TYPE_NAME("virt-2.5"),
     .parent = TYPE_VIRT_MACHINE,
-    .instance_init = virt_instance_init,
-    .class_init = virt_class_init,
+    .instance_init = virt_2_5_instance_init,
+    .class_init = virt_2_5_class_init,
 };
 
 static void machvirt_machine_init(void)
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types

[Peter Maydell]

On 22 February 2016 at 21:06, Wei Huang <wei@redhat.com> wrote:
> We start to see more features been added to ARM virtual machine models.
> For the purpose of backward compatibility (e.g. migration), it is time
> to consider versioning machine types for ARM VMs. As a beginning step, this
> patchset defines an abstract machine type for ARM VMs. The current
> "virt" machine is re-written based on this new machine type accordingly.
> These patches have been verified by booting existing VMs.
>
> Note that I am seeking inputs from the community by putting RFC in the
> subject line. Please let me know your opinions. I will send out V1
> afterwards.

My view here is the same as it has been in the past regarding
adding versioned machine types for 'virt': are you (in this case
Redhat) willing to stand behind it, in the sense of taking on
the maintenance burden of adding new machine versions, reviewing
new code contributions for issues that require changes to make sure
that the old versions stay looking like the old machine, testing
that old versions look right, testing cross version migration,
and so on?

We need versioned machine types at *some* point; my intent here
is to provide sufficient pushback to ensure that we don't give
ourselves the maintenance headache until we truly need it...

thanks
-- PMM

Re: [Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types

[Wei Huang]

On 02/22/2016 04:14 PM, Peter Maydell wrote:
> On 22 February 2016 at 21:06, Wei Huang <wei@redhat.com> wrote:
>> We start to see more features been added to ARM virtual machine models.
>> For the purpose of backward compatibility (e.g. migration), it is time
>> to consider versioning machine types for ARM VMs. As a beginning step, this
>> patchset defines an abstract machine type for ARM VMs. The current
>> "virt" machine is re-written based on this new machine type accordingly.
>> These patches have been verified by booting existing VMs.
>>
>> Note that I am seeking inputs from the community by putting RFC in the
>> subject line. Please let me know your opinions. I will send out V1
>> afterwards.
> 
> My view here is the same as it has been in the past regarding
> adding versioned machine types for 'virt': are you (in this case
> Redhat) willing to stand behind it, in the sense of taking on
> the maintenance burden of adding new machine versions, reviewing
> new code contributions for issues that require changes to make sure
> that the old versions stay looking like the old machine, testing
> that old versions look right, testing cross version migration,
> and so on?

I understand your concerns. Currently our in-house tree already carries
versioned ARM machine types, which mirror both QEMU 2.4 and QEMU 2.5.
Thus someone (including myself) from Red Hat shouldn't have any problem
of maintaining/testing it because we are already doing it downstream.
x86 and ppc have a similar situation.

> 
> We need versioned machine types at *some* point; my intent here
> is to provide sufficient pushback to ensure that we don't give
> ourselves the maintenance headache until we truly need it...
> 

mach-virt based products are coming soon, so versioning is just around
the corner. The advantage of introducing it upstream early is that the
upper layers in the stack have a chance to integrate, and the QEMU
downstreams don't need to diverge in how they add versioning support
themselves. This benefits not only Red Hat but also other companies.

Thanks,
-Wei

> thanks
> -- PMM
> 

Re: [Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types

[Peter Maydell]

On 23 February 2016 at 18:34, Wei Huang <wei@redhat.com> wrote:
> On 02/22/2016 04:14 PM, Peter Maydell wrote:
>> My view here is the same as it has been in the past regarding
>> adding versioned machine types for 'virt': are you (in this case
>> Redhat) willing to stand behind it, in the sense of taking on
>> the maintenance burden of adding new machine versions, reviewing
>> new code contributions for issues that require changes to make sure
>> that the old versions stay looking like the old machine, testing
>> that old versions look right, testing cross version migration,
>> and so on?
>
> I understand your concerns. Currently our in-house tree already carries
> versioned ARM machine types, which mirror both QEMU 2.4 and QEMU 2.5.
> Thus someone (including myself) from Red Hat shouldn't have any problem
> of maintaining/testing it because we are already doing it downstream.
> x86 and ppc have a similar situation.

Thanks for the clarification -- if you as a distro are already
supporting versioned machine types downstream that's a strong
argument for adding it upstream.

-- PMM

Re: [Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types

[Andrew Jones]

On Tue, Feb 23, 2016 at 06:42:16PM +0000, Peter Maydell wrote:
> On 23 February 2016 at 18:34, Wei Huang <wei@redhat.com> wrote:
> > On 02/22/2016 04:14 PM, Peter Maydell wrote:
> >> My view here is the same as it has been in the past regarding
> >> adding versioned machine types for 'virt': are you (in this case
> >> Redhat) willing to stand behind it, in the sense of taking on
> >> the maintenance burden of adding new machine versions, reviewing
> >> new code contributions for issues that require changes to make sure
> >> that the old versions stay looking like the old machine, testing
> >> that old versions look right, testing cross version migration,
> >> and so on?
> >
> > I understand your concerns. Currently our in-house tree already carries
> > versioned ARM machine types, which mirror both QEMU 2.4 and QEMU 2.5.
> > Thus someone (including myself) from Red Hat shouldn't have any problem
> > of maintaining/testing it because we are already doing it downstream.
> > x86 and ppc have a similar situation.
> 
> Thanks for the clarification -- if you as a distro are already
> supporting versioned machine types downstream that's a strong
> argument for adding it upstream.

Unfortunately the word 'support' is super overloaded in this field. I'll
just quick clarify. We have a series of pre-releases for our virt stack.
Later pre-release releases are based on later QEMU, and thus we've
versioned mach-virt already. But, as they're just pre-releases, they
aren't supported in the sense that we're working bug reports against
them.

I believe our downstream versioning has driven some changes to libvirt
already, so I think it's a good time to bring the how to best version
mach-virt discussions to all the respective upstreams, despite it
currently, at least for us, being used only on pre-releases though.

Thanks,
drew

Re: [Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types

[Peter Maydell]

On 24 February 2016 at 02:09, Andrew Jones <drjones@redhat.com> wrote:
> I believe our downstream versioning has driven some changes to libvirt
> already, so I think it's a good time to bring the how to best version
> mach-virt discussions to all the respective upstreams, despite it
> currently, at least for us, being used only on pre-releases though.

So, to sum up from a conversation today:

 * We should add versioning to 'virt' now
 * We should do it by having the QEMU 2.6 release have a "virt-2.6"
   which is the same as "virt" for this upstream release
 * Then from 2.6 forward we start creating "virt-2.7", etc machines
   and making sure we have properties etc so that "virt-2.6" remains
   the same config as the 2.6 release's virt board.
 * RedHat are doing this for downstream anyway so will take on the
   task of monitoring changes to the virt board and submitting the
   relevant patches to property-ify things. (Better still, if you
   make comments during code review you can get patch submitters to
   do the work for you ;-). I will attempt to spot this kind of thing
   when I review patches to the virt board but I will probably miss
   things especially at first.)

Practically:
 * Wei, you need to respin this patchset, because as it stands it
   creates a "virt-2.5", and it should be "virt-2.6". If you do that
   then I think it's generally OK to go in.
 * My only other review comment is that patch 1 sets mc->is_default
   which gives qemu-system-aarch64 a default board. We deliberately
   don't have a default machine type for ARM, so please don't do that.
   (We can have that discussion if you like but it's a separate issue
   so best not tangled up with this patchset.)

thanks
-- PMM