On Tue, Jun 24, 2014 at 02:55:20PM -0300, Eduardo Habkost wrote: > On Tue, Jun 24, 2014 at 05:47:53PM +0100, Peter Maydell wrote: > > On 24 June 2014 17:44, Eduardo Habkost <ehabk...@redhat.com> wrote: > > > (I would go even further and say that no compat_props bit need to be > > > specific to a machine-type family, and they are simply tied to the code > > > included in a QEMU version. So every PC_COMPAT_* bit could go to a > > > common QEMU_COMPAT_<version> macro, that could be reusable by all > > > machine-types, and there's no need PC-specific compat macros.) > > > > What if different machines in a particular release had the > > property set to different defaults? > > I never saw that happen, and I don't think it is even likely: default > values set in instance_init, and compat_props are applied just after > instance_init, before object_new() returns. So a machine-type would need > to find a way to change fields after instance_init but before > compat_props are applied. > > Anyway, if a machine-type really needs that, it can still have its own > set of compat macros to implement machine-type-specific compat_props. My > point is that there's no need for that on the PC code today.
I just found a potential counter-example: the hpet.hpet-intcap compat property. The current hpet.hpet-intcap=0x4 compat property on q35 can (should?) be applied to both piix and q35 machine-types, because 0x4 was the default for both machine-types when the hpet-intcap property was introduced. But now the machine-type initialization code for piix and q35 emulate different defaults by checking if the property is set to zero (which is the actual default on the hpet code). So, if one day we decide to change the hpet-intcap default on piix or q35, we will need different compat_props on each one. But by now we can still keep the code simple and have a single set of compat macros for both. -- Eduardo
