diff options
author | Eduardo Habkost | 2014-06-25 04:04:44 +0200 |
---|---|---|
committer | Michael S. Tsirkin | 2014-06-29 17:59:06 +0200 |
commit | b8f5cfd6824ee7122e714ffc7e893432dd7beae5 (patch) | |
tree | 2ac9fc062124482dc5ccc54f194eef4808baded2 /include/hw/net | |
parent | numa: fix comment (diff) | |
download | qemu-b8f5cfd6824ee7122e714ffc7e893432dd7beae5.tar.gz qemu-b8f5cfd6824ee7122e714ffc7e893432dd7beae5.tar.xz qemu-b8f5cfd6824ee7122e714ffc7e893432dd7beae5.zip |
pc: Move q35 compat props to PC_COMPAT_*
For each compat property on PC_Q35_COMPAT_*, there are only two
possibilities:
* If the device is never instantiated when using a machine other than
pc-q35, then the compat property can be safely added to
PC_COMPAT_*;
* If the device can be instantiated when using a machine other than
pc-q35, that means the other machines also need the compat property
to be set.
That means we don't need separate PC_Q35_COMPAT_* macros at all, today.
The hpet.hpet-intcap case is interesting: piix and q35 do have something
that emulates different defaults, but the machine-specific default is
applied _after_ compat_props are applied, by simply checking if the
property is zero (which is the real default on the hpet code).
The hpet.hpet-intcap=0x4 compat property can (should?) be applied to
piix too, because 0x4 was the default on both piix and q35 before the
hpet-intcap property was introduced.
Now, if one day we change the default HPET intcap on one of the PC
machine-types again, we may want to introduce PC_{Q35,I440FX}_COMPAT
macros. But while we don't need that, we can keep the code simple.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'include/hw/net')
0 files changed, 0 insertions, 0 deletions