diff options
author | Eduardo Habkost <ehabkost@redhat.com> | 2015-10-30 17:36:07 -0200 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2015-11-04 15:02:30 +0100 |
commit | de796d93f59d363409dfd9e186ccd64a21f92204 (patch) | |
tree | 623745876ce8c9231fe02adda638c76947530be2 /net/tap-aix.c | |
parent | ddcc8e9d51c415a7b7b2983c3552408d9a50be6e (diff) | |
download | hqemu-de796d93f59d363409dfd9e186ccd64a21f92204.zip hqemu-de796d93f59d363409dfd9e186ccd64a21f92204.tar.gz |
pc: Set hw_version on all machine classes
In 2012, QEMU had a bug where it exposed QEMU version information to the
guest, meaning a QEMU upgrade would expose different hardware to the
guest OS even if the same machine-type is being used.
The bug was fixed by commit 93bfef4c6e4b23caea9d51e1099d06433d8835a4, on
all machines up to pc-1.0. But we kept introducing the same bug on all
newer machines since then. That means we are breaking guest ABI every
time QEMU was upgraded.
Fix this by setting the hw_version on all PC machines, making sure the
hardware won't change when upgrading QEMU.
Note that QEMU_VERSION was "1.0" in QEMU 1.0, but starting on QEMU
1.1.0, it started following the "x.y.0" pattern. We have to follow it,
to make sure we use the right QEMU_VERSION string from each QEMU
release.
The 2.5 machine classes could have hw_version unset, because the default
value for qemu_get_version() is QEMU_VERSION. But I decided to set it
explicitly to QEMU_VERSION so we don't forget to update it to "2.5.0"
after we release 2.5.0 and create a 2.6 machine class.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <1446233769-7892-2-git-send-email-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'net/tap-aix.c')
0 files changed, 0 insertions, 0 deletions