| Message ID | 1453978688-222752-1-git-send-email-imammedo@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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(-) [...]
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(-) > [...] >
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>
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?
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
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
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
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
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
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)
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.
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 >
"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.
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
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?
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 --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();
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(-)