diff mbox

[v19,7/9] machine: add properties to compat_props incrementaly

Message ID 1453978688-222752-1-git-send-email-imammedo@redhat.com (mailing list archive)
State New, archived
Headers show

Commit Message

Igor Mammedov Jan. 28, 2016, 10:58 a.m. UTC
Switch to adding compat properties incrementaly instead of
completly overwriting compat_props per machine type.
That removes data duplication which we have due to nested
[PC|SPAPR]_COMPAT_* macros.

It also allows to set default device properties from
default foo_machine_options() hook, which will be used
in following patch for putting VMGENID device as
a function if ISA bridge on pc/q35 machines.

Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>

compat_props GArray
---
 hw/core/machine.c          | 10 ++++++++++
 hw/ppc/spapr.c             |  3 ---
 hw/s390x/s390-virtio-ccw.c | 12 ++----------
 include/hw/boards.h        | 11 +++++++++--
 include/hw/i386/pc.h       |  9 ---------
 vl.c                       |  6 +++++-
 6 files changed, 26 insertions(+), 25 deletions(-)

Comments

Eduardo Habkost Jan. 28, 2016, 2:02 p.m. UTC | #1
On Thu, Jan 28, 2016 at 11:58:08AM +0100, Igor Mammedov wrote:
> Switch to adding compat properties incrementaly instead of
> completly overwriting compat_props per machine type.
> That removes data duplication which we have due to nested
> [PC|SPAPR]_COMPAT_* macros.
> 
> It also allows to set default device properties from
> default foo_machine_options() hook, which will be used
> in following patch for putting VMGENID device as
> a function if ISA bridge on pc/q35 machines.
> 
> Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> 

Very nice. The only suggestion I have is to use the simpler GList
type, instead of GArray.

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>

> compat_props GArray

I assume this line was left here by mistake?

> ---
>  hw/core/machine.c          | 10 ++++++++++
>  hw/ppc/spapr.c             |  3 ---
>  hw/s390x/s390-virtio-ccw.c | 12 ++----------
>  include/hw/boards.h        | 11 +++++++++--
>  include/hw/i386/pc.h       |  9 ---------
>  vl.c                       |  6 +++++-
>  6 files changed, 26 insertions(+), 25 deletions(-)
[...]
Igor Mammedov Jan. 28, 2016, 5 p.m. UTC | #2
On Thu, 28 Jan 2016 12:02:12 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Jan 28, 2016 at 11:58:08AM +0100, Igor Mammedov wrote:
> > Switch to adding compat properties incrementaly instead of
> > completly overwriting compat_props per machine type.
> > That removes data duplication which we have due to nested
> > [PC|SPAPR]_COMPAT_* macros.
> > 
> > It also allows to set default device properties from
> > default foo_machine_options() hook, which will be used
> > in following patch for putting VMGENID device as
> > a function if ISA bridge on pc/q35 machines.
> > 
> > Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> >   
> 
> Very nice. The only suggestion I have is to use the simpler GList
> type, instead of GArray.
It's fine with me to use GList here as well,
fill free to pick this patch in case you'd like to do it.
it should be trivial to swap from one type to another.

It looks like this series might go nowhere but this patch
is not tied to it and useful to us in general
so perhaps you could pick it up after ACKs from
S390/SPAPR maintainers.

> 
> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> 
> > compat_props GArray  
> 
> I assume this line was left here by mistake?
yep, it's leftover from squashing fixup.

> 
> > ---
> >  hw/core/machine.c          | 10 ++++++++++
> >  hw/ppc/spapr.c             |  3 ---
> >  hw/s390x/s390-virtio-ccw.c | 12 ++----------
> >  include/hw/boards.h        | 11 +++++++++--
> >  include/hw/i386/pc.h       |  9 ---------
> >  vl.c                       |  6 +++++-
> >  6 files changed, 26 insertions(+), 25 deletions(-)  
> [...]
>
Cornelia Huck Jan. 29, 2016, 12:51 p.m. UTC | #3
On Thu, 28 Jan 2016 11:58:08 +0100
Igor Mammedov <imammedo@redhat.com> wrote:

> Switch to adding compat properties incrementaly instead of
> completly overwriting compat_props per machine type.
> That removes data duplication which we have due to nested
> [PC|SPAPR]_COMPAT_* macros.

We'll try to switch to something similar to spapr for ccw so we can get
rid of the nesting as well (once one of us has time to look into that).

> 
> It also allows to set default device properties from
> default foo_machine_options() hook, which will be used
> in following patch for putting VMGENID device as
> a function if ISA bridge on pc/q35 machines.
> 
> Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>

master + this patch (+ <20160115120143.GB2432@work-vm>) survives some
playing around with virsh managedsave and the 2.4/2.5/2.6 ccw machines,
so

Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Eduardo Habkost Feb. 3, 2016, 5:55 p.m. UTC | #4
On Thu, Jan 28, 2016 at 06:00:31PM +0100, Igor Mammedov wrote:
[...]
> It looks like this series might go nowhere but this patch
> is not tied to it and useful to us in general
> so perhaps you could pick it up after ACKs from
> S390/SPAPR maintainers.
> 
> > 
> > Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>

We don't have a maintainer for hw/core/machine.c, hw/core/qdev*,
and related files.

Assuming we don't have a volunteer to maintain them officially,
can we agree on a default destination for those patches so they
don't linger on the list? Michael? Andreas?
Laszlo Ersek Feb. 3, 2016, 6:46 p.m. UTC | #5
On 02/03/16 18:55, Eduardo Habkost wrote:
> On Thu, Jan 28, 2016 at 06:00:31PM +0100, Igor Mammedov wrote:
> [...]
>> It looks like this series might go nowhere but this patch
>> is not tied to it and useful to us in general
>> so perhaps you could pick it up after ACKs from
>> S390/SPAPR maintainers.
>>
>>>
>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> 
> We don't have a maintainer for hw/core/machine.c, hw/core/qdev*,
> and related files.
> 
> Assuming we don't have a volunteer to maintain them officially,
> can we agree on a default destination for those patches so they
> don't linger on the list? Michael? Andreas?

Preferably someone who is otherwise not incessantly overloaded by
patches to review.

Just my two cents.

Laszlo
Michael S. Tsirkin Feb. 3, 2016, 7:06 p.m. UTC | #6
On Wed, Feb 03, 2016 at 03:55:04PM -0200, Eduardo Habkost wrote:
> On Thu, Jan 28, 2016 at 06:00:31PM +0100, Igor Mammedov wrote:
> [...]
> > It looks like this series might go nowhere but this patch
> > is not tied to it and useful to us in general
> > so perhaps you could pick it up after ACKs from
> > S390/SPAPR maintainers.
> > 
> > > 
> > > Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> 
> We don't have a maintainer for hw/core/machine.c, hw/core/qdev*,
> and related files.
> 
> Assuming we don't have a volunteer to maintain them officially,
> can we agree on a default destination for those patches so they
> don't linger on the list? Michael? Andreas?

Not me please. Have too much on my plate.
Would you like to maintain it yourself?

> -- 
> Eduardo
Paolo Bonzini Feb. 4, 2016, 11:31 a.m. UTC | #7
On 03/02/2016 20:06, Michael S. Tsirkin wrote:
> On Wed, Feb 03, 2016 at 03:55:04PM -0200, Eduardo Habkost wrote:
>> On Thu, Jan 28, 2016 at 06:00:31PM +0100, Igor Mammedov wrote:
>> [...]
>>> It looks like this series might go nowhere but this patch
>>> is not tied to it and useful to us in general
>>> so perhaps you could pick it up after ACKs from
>>> S390/SPAPR maintainers.
>>>
>>>>
>>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>>
>> We don't have a maintainer for hw/core/machine.c, hw/core/qdev*,
>> and related files.
>>
>> Assuming we don't have a volunteer to maintain them officially,
>> can we agree on a default destination for those patches so they
>> don't linger on the list? Michael? Andreas?
> 
> Not me please. Have too much on my plate.
> Would you like to maintain it yourself?

That's my suggestion too.  I guess Igor and I could help with reviews,
but testing and sending the pull requests would add too much work.
Since you're the main one touching it, it makes sense for you to handle it.

Paolo
Andreas Färber Feb. 4, 2016, 11:41 a.m. UTC | #8
Am 04.02.2016 um 12:31 schrieb Paolo Bonzini:
> On 03/02/2016 20:06, Michael S. Tsirkin wrote:
>> On Wed, Feb 03, 2016 at 03:55:04PM -0200, Eduardo Habkost wrote:
>>> On Thu, Jan 28, 2016 at 06:00:31PM +0100, Igor Mammedov wrote:
>>> [...]
>>>> It looks like this series might go nowhere but this patch
>>>> is not tied to it and useful to us in general
>>>> so perhaps you could pick it up after ACKs from
>>>> S390/SPAPR maintainers.
>>>>
>>>>>
>>>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>>>
>>> We don't have a maintainer for hw/core/machine.c, hw/core/qdev*,
>>> and related files.
>>>
>>> Assuming we don't have a volunteer to maintain them officially,
>>> can we agree on a default destination for those patches so they
>>> don't linger on the list? Michael? Andreas?
>>
>> Not me please. Have too much on my plate.
>> Would you like to maintain it yourself?
> 
> That's my suggestion too.  I guess Igor and I could help with reviews,
> but testing and sending the pull requests would add too much work.
> Since you're the main one touching it, it makes sense for you to handle it.

You're talking about machine, right? Some time ago I had proposed Marcel
who initially worked on it, but I'm fine with anyone taking it.

For some (but not all) core qdev parts related to the (stalled) QOM
migration I've been taking care of via qom-next. Last time this came up
you didn't want anyone to be M: for qdev, so maybe we can use R: so that
at least people automatically get CC'ed and we avoid this recurring
discussion?

Regards,
Andreas
Paolo Bonzini Feb. 4, 2016, 11:55 a.m. UTC | #9
On 04/02/2016 12:41, Andreas Färber wrote:
> You're talking about machine, right? Some time ago I had proposed Marcel
> who initially worked on it, but I'm fine with anyone taking it.

Yes.

> For some (but not all) core qdev parts related to the (stalled) QOM
> migration I've been taking care of via qom-next. Last time this came up
> you didn't want anyone to be M: for qdev, so maybe we can use R: so that
> at least people automatically get CC'ed and we avoid this recurring
> discussion?

I might have changed my mind on that.  You definitely should be M: for qdev.

Paolo
Michael S. Tsirkin Feb. 4, 2016, 12:03 p.m. UTC | #10
On Thu, Feb 04, 2016 at 12:41:39PM +0100, Andreas Färber wrote:
> Am 04.02.2016 um 12:31 schrieb Paolo Bonzini:
> > On 03/02/2016 20:06, Michael S. Tsirkin wrote:
> >> On Wed, Feb 03, 2016 at 03:55:04PM -0200, Eduardo Habkost wrote:
> >>> On Thu, Jan 28, 2016 at 06:00:31PM +0100, Igor Mammedov wrote:
> >>> [...]
> >>>> It looks like this series might go nowhere but this patch
> >>>> is not tied to it and useful to us in general
> >>>> so perhaps you could pick it up after ACKs from
> >>>> S390/SPAPR maintainers.
> >>>>
> >>>>>
> >>>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> >>>
> >>> We don't have a maintainer for hw/core/machine.c, hw/core/qdev*,
> >>> and related files.
> >>>
> >>> Assuming we don't have a volunteer to maintain them officially,
> >>> can we agree on a default destination for those patches so they
> >>> don't linger on the list? Michael? Andreas?
> >>
> >> Not me please. Have too much on my plate.
> >> Would you like to maintain it yourself?
> > 
> > That's my suggestion too.  I guess Igor and I could help with reviews,
> > but testing and sending the pull requests would add too much work.
> > Since you're the main one touching it, it makes sense for you to handle it.
> 
> You're talking about machine, right? Some time ago I had proposed Marcel
> who initially worked on it, but I'm fine with anyone taking it.

Sure, Marcel can do it too.

> 
> For some (but not all) core qdev parts related to the (stalled) QOM
> migration I've been taking care of via qom-next. Last time this came up
> you didn't want anyone to be M: for qdev, so maybe we can use R: so that
> at least people automatically get CC'ed and we avoid this recurring
> discussion?
> 
> Regards,
> Andreas

I think that was because core was not changing much, so merging through
other trees was more appropriate, but that changed.

So it appears we already can have
M: Eduardo Habkost <ehabkost@redhat.com>
M: Marcel Apfelbaum <marcel@redhat.com>

This should spread the review load nicely.

> -- 
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
Michael S. Tsirkin Feb. 4, 2016, 12:06 p.m. UTC | #11
On Thu, Feb 04, 2016 at 12:55:22PM +0100, Paolo Bonzini wrote:
> 
> 
> On 04/02/2016 12:41, Andreas Färber wrote:
> > You're talking about machine, right? Some time ago I had proposed Marcel
> > who initially worked on it, but I'm fine with anyone taking it.
> 
> Yes.
> 
> > For some (but not all) core qdev parts related to the (stalled) QOM
> > migration I've been taking care of via qom-next. Last time this came up
> > you didn't want anyone to be M: for qdev, so maybe we can use R: so that
> > at least people automatically get CC'ed and we avoid this recurring
> > discussion?
> 
> I might have changed my mind on that.  You definitely should be M: for qdev.
> 
> Paolo

If Andreas wants to, that's also fine. Several maintainers are
better than one.
Marcel Apfelbaum Feb. 4, 2016, 12:12 p.m. UTC | #12
On 02/04/2016 01:41 PM, Andreas Färber wrote:
> Am 04.02.2016 um 12:31 schrieb Paolo Bonzini:
>> On 03/02/2016 20:06, Michael S. Tsirkin wrote:
>>> On Wed, Feb 03, 2016 at 03:55:04PM -0200, Eduardo Habkost wrote:
>>>> On Thu, Jan 28, 2016 at 06:00:31PM +0100, Igor Mammedov wrote:
>>>> [...]
>>>>> It looks like this series might go nowhere but this patch
>>>>> is not tied to it and useful to us in general
>>>>> so perhaps you could pick it up after ACKs from
>>>>> S390/SPAPR maintainers.
>>>>>
>>>>>>
>>>>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>>>>
>>>> We don't have a maintainer for hw/core/machine.c, hw/core/qdev*,
>>>> and related files.
>>>>
>>>> Assuming we don't have a volunteer to maintain them officially,
>>>> can we agree on a default destination for those patches so they
>>>> don't linger on the list? Michael? Andreas?
>>>
>>> Not me please. Have too much on my plate.
>>> Would you like to maintain it yourself?
>>
>> That's my suggestion too.  I guess Igor and I could help with reviews,
>> but testing and sending the pull requests would add too much work.
>> Since you're the main one touching it, it makes sense for you to handle it.
>
> You're talking about machine, right? Some time ago I had proposed Marcel
> who initially worked on it, but I'm fine with anyone taking it.

Hi,

As I previously said I can maintain the machine and the related code.
I'll gladly help Eduardo with reviews or have a tree ready for machine/qdev
and send pull requests if Peter agrees to it.

Eduardo, Peter what is your take on this?

Thanks,
Marcel


>
> For some (but not all) core qdev parts related to the (stalled) QOM
> migration I've been taking care of via qom-next. Last time this came up
> you didn't want anyone to be M: for qdev, so maybe we can use R: so that
> at least people automatically get CC'ed and we avoid this recurring
> discussion?
>
> Regards,
> Andreas
>
Markus Armbruster Feb. 5, 2016, 7:49 a.m. UTC | #13
"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Thu, Feb 04, 2016 at 12:55:22PM +0100, Paolo Bonzini wrote:
>> 
>> 
>> On 04/02/2016 12:41, Andreas Färber wrote:
>> > You're talking about machine, right? Some time ago I had proposed Marcel
>> > who initially worked on it, but I'm fine with anyone taking it.
>> 
>> Yes.
>> 
>> > For some (but not all) core qdev parts related to the (stalled) QOM
>> > migration I've been taking care of via qom-next. Last time this came up
>> > you didn't want anyone to be M: for qdev, so maybe we can use R: so that
>> > at least people automatically get CC'ed and we avoid this recurring
>> > discussion?
>> 
>> I might have changed my mind on that.  You definitely should be M: for qdev.
>> 
>> Paolo
>
> If Andreas wants to, that's also fine. Several maintainers are
> better than one.

*If* the maintainers are all willing and able to work together.
Marcel Apfelbaum Feb. 5, 2016, 7:51 a.m. UTC | #14
On 02/05/2016 09:49 AM, Markus Armbruster wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
>> On Thu, Feb 04, 2016 at 12:55:22PM +0100, Paolo Bonzini wrote:
>>>
>>>
>>> On 04/02/2016 12:41, Andreas Färber wrote:
>>>> You're talking about machine, right? Some time ago I had proposed Marcel
>>>> who initially worked on it, but I'm fine with anyone taking it.
>>>
>>> Yes.
>>>
>>>> For some (but not all) core qdev parts related to the (stalled) QOM
>>>> migration I've been taking care of via qom-next. Last time this came up
>>>> you didn't want anyone to be M: for qdev, so maybe we can use R: so that
>>>> at least people automatically get CC'ed and we avoid this recurring
>>>> discussion?
>>>
>>> I might have changed my mind on that.  You definitely should be M: for qdev.
>>>
>>> Paolo
>>
>> If Andreas wants to, that's also fine. Several maintainers are
>> better than one.
>
> *If* the maintainers are all willing and able to work together.
>

No problem here from my point of view :)

Thanks,
Marcel
Markus Armbruster Feb. 5, 2016, 7:52 a.m. UTC | #15
Paolo Bonzini <pbonzini@redhat.com> writes:

> On 04/02/2016 12:41, Andreas Färber wrote:
>> You're talking about machine, right? Some time ago I had proposed Marcel
>> who initially worked on it, but I'm fine with anyone taking it.
>
> Yes.
>
>> For some (but not all) core qdev parts related to the (stalled) QOM
>> migration I've been taking care of via qom-next. Last time this came up
>> you didn't want anyone to be M: for qdev, so maybe we can use R: so that
>> at least people automatically get CC'ed and we avoid this recurring
>> discussion?
>
> I might have changed my mind on that.  You definitely should be M: for qdev.

Yes.  Would you like co-maintainers for just qdev, for QOM+qdev, or
simply add qdev to your QOM portfolio?
Eduardo Habkost Feb. 11, 2016, 7:41 p.m. UTC | #16
On Fri, Feb 05, 2016 at 09:51:07AM +0200, Marcel Apfelbaum wrote:
> On 02/05/2016 09:49 AM, Markus Armbruster wrote:
> >"Michael S. Tsirkin" <mst@redhat.com> writes:
> >
> >>On Thu, Feb 04, 2016 at 12:55:22PM +0100, Paolo Bonzini wrote:
> >>>
> >>>
> >>>On 04/02/2016 12:41, Andreas Färber wrote:
> >>>>You're talking about machine, right? Some time ago I had proposed Marcel
> >>>>who initially worked on it, but I'm fine with anyone taking it.
> >>>
> >>>Yes.
> >>>
> >>>>For some (but not all) core qdev parts related to the (stalled) QOM
> >>>>migration I've been taking care of via qom-next. Last time this came up
> >>>>you didn't want anyone to be M: for qdev, so maybe we can use R: so that
> >>>>at least people automatically get CC'ed and we avoid this recurring
> >>>>discussion?
> >>>
> >>>I might have changed my mind on that.  You definitely should be M: for qdev.
> >>>
> >>>Paolo
> >>
> >>If Andreas wants to, that's also fine. Several maintainers are
> >>better than one.
> >
> >*If* the maintainers are all willing and able to work together.
> >
> 
> No problem here from my point of view :)

No problem to me, too. :)

I am going to be away from work for 15 days starting on Tuesday
Feb 16th. So if Marcel wants to start queueing patches already,
please be my guest. I will be able to help on that after I'm
back.
diff mbox

Patch

diff --git a/hw/core/machine.c b/hw/core/machine.c
index c46ddc7..2b96f47 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -526,6 +526,15 @@  bool machine_mem_merge(MachineState *machine)
     return machine->mem_merge;
 }
 
+static void machine_class_finalize(ObjectClass *klass, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(klass);
+
+    if (mc->compat_props) {
+        g_array_free(mc->compat_props, true);
+    }
+}
+
 static const TypeInfo machine_info = {
     .name = TYPE_MACHINE,
     .parent = TYPE_OBJECT,
@@ -533,6 +542,7 @@  static const TypeInfo machine_info = {
     .class_size = sizeof(MachineClass),
     .class_init    = machine_class_init,
     .class_base_init = machine_class_base_init,
+    .class_finalize = machine_class_finalize,
     .instance_size = sizeof(MachineState),
     .instance_init = machine_initfn,
     .instance_finalize = machine_finalize,
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 50e5a26..4ec1156 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2412,7 +2412,6 @@  DEFINE_SPAPR_MACHINE(2_4, "2.4", false);
  * pseries-2.3
  */
 #define SPAPR_COMPAT_2_3 \
-        SPAPR_COMPAT_2_4 \
         HW_COMPAT_2_3 \
         {\
             .driver   = "spapr-pci-host-bridge",\
@@ -2439,7 +2438,6 @@  DEFINE_SPAPR_MACHINE(2_3, "2.3", false);
  */
 
 #define SPAPR_COMPAT_2_2 \
-        SPAPR_COMPAT_2_3 \
         HW_COMPAT_2_2 \
         {\
             .driver   = TYPE_SPAPR_PCI_HOST_BRIDGE,\
@@ -2463,7 +2461,6 @@  DEFINE_SPAPR_MACHINE(2_2, "2.2", false);
  * pseries-2.1
  */
 #define SPAPR_COMPAT_2_1 \
-        SPAPR_COMPAT_2_2 \
         HW_COMPAT_2_1
 
 static void spapr_machine_2_1_instance_options(MachineState *machine)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 586ddbb..0d3c3f8 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -282,13 +282,9 @@  static const TypeInfo ccw_machine_info = {
 static void ccw_machine_2_4_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
-    static GlobalProperty compat_props[] = {
-        CCW_COMPAT_2_4
-        { /* end of list */ }
-    };
 
     mc->desc = "VirtIO-ccw based S390 machine v2.4";
-    mc->compat_props = compat_props;
+    SET_MACHINE_COMPAT(mc, CCW_COMPAT_2_4);
 }
 
 static const TypeInfo ccw_machine_2_4_info = {
@@ -300,13 +296,9 @@  static const TypeInfo ccw_machine_2_4_info = {
 static void ccw_machine_2_5_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
-    static GlobalProperty compat_props[] = {
-        CCW_COMPAT_2_5
-        { /* end of list */ }
-    };
 
     mc->desc = "VirtIO-ccw based S390 machine v2.5";
-    mc->compat_props = compat_props;
+    SET_MACHINE_COMPAT(mc, CCW_COMPAT_2_5);
 }
 
 static const TypeInfo ccw_machine_2_5_info = {
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 0f30959..cdb4a98 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -90,7 +90,7 @@  struct MachineClass {
     const char *default_machine_opts;
     const char *default_boot_order;
     const char *default_display;
-    GlobalProperty *compat_props;
+    GArray *compat_props;
     const char *hw_version;
     ram_addr_t default_ram_size;
     bool option_rom_has_mr;
@@ -159,11 +159,18 @@  struct MachineState {
 
 #define SET_MACHINE_COMPAT(m, COMPAT) \
     do {                              \
+        int i;                        \
         static GlobalProperty props[] = {       \
             COMPAT                              \
             { /* end of list */ }               \
         };                                      \
-        (m)->compat_props = props;              \
+        if (!m->compat_props) { \
+            m->compat_props = g_array_new(false, false, sizeof(void *)); \
+        } \
+        for (i = 0; props[i].driver != NULL; i++) {    \
+            GlobalProperty *prop = &props[i];          \
+            g_array_append_val(m->compat_props, prop); \
+        }                                              \
     } while (0)
 
 #endif
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 65e8f24..7713361 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -361,7 +361,6 @@  bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
     HW_COMPAT_2_5
 
 #define PC_COMPAT_2_4 \
-    PC_COMPAT_2_5 \
     HW_COMPAT_2_4 \
     {\
         .driver   = "Haswell-" TYPE_X86_CPU,\
@@ -432,7 +431,6 @@  bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
 
 #define PC_COMPAT_2_3 \
-    PC_COMPAT_2_4 \
     HW_COMPAT_2_3 \
     {\
         .driver   = TYPE_X86_CPU,\
@@ -513,7 +511,6 @@  bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
     },
 
 #define PC_COMPAT_2_2 \
-    PC_COMPAT_2_3 \
     HW_COMPAT_2_2 \
     {\
         .driver = "kvm64" "-" TYPE_X86_CPU,\
@@ -607,7 +604,6 @@  bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
     },
 
 #define PC_COMPAT_2_1 \
-    PC_COMPAT_2_2 \
     HW_COMPAT_2_1 \
     {\
         .driver = "coreduo" "-" TYPE_X86_CPU,\
@@ -621,7 +617,6 @@  bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
     },
 
 #define PC_COMPAT_2_0 \
-    PC_COMPAT_2_1 \
     {\
         .driver   = "virtio-scsi-pci",\
         .property = "any_layout",\
@@ -681,7 +676,6 @@  bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
     },
 
 #define PC_COMPAT_1_7 \
-    PC_COMPAT_2_0 \
     {\
         .driver   = TYPE_USB_DEVICE,\
         .property = "msos-desc",\
@@ -699,7 +693,6 @@  bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
     },
 
 #define PC_COMPAT_1_6 \
-    PC_COMPAT_1_7 \
     {\
         .driver   = "e1000",\
         .property = "mitigation",\
@@ -723,7 +716,6 @@  bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
     },
 
 #define PC_COMPAT_1_5 \
-    PC_COMPAT_1_6 \
     {\
         .driver   = "Conroe-" TYPE_X86_CPU,\
         .property = "model",\
@@ -767,7 +759,6 @@  bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
     },
 
 #define PC_COMPAT_1_4 \
-    PC_COMPAT_1_5 \
     {\
         .driver   = "scsi-hd",\
         .property = "discard_granularity",\
diff --git a/vl.c b/vl.c
index f043009..cf103d7 100644
--- a/vl.c
+++ b/vl.c
@@ -4492,7 +4492,11 @@  int main(int argc, char **argv, char **envp)
     }
 
     if (machine_class->compat_props) {
-        qdev_prop_register_global_list(machine_class->compat_props);
+        GlobalProperty *p;
+        for (i = 0; i < machine_class->compat_props->len; i++) {
+            p = g_array_index(machine_class->compat_props, GlobalProperty *, i);
+            qdev_prop_register_global(p);
+        }
     }
     qemu_add_globals();