aboutsummaryrefslogtreecommitdiff
path: root/vl.c
diff options
context:
space:
mode:
authorEduardo Habkost <ehabkost@redhat.com>2015-10-30 17:36:07 -0200
committerPaolo Bonzini <pbonzini@redhat.com>2015-11-04 15:02:30 +0100
commitde796d93f59d363409dfd9e186ccd64a21f92204 (patch)
tree623745876ce8c9231fe02adda638c76947530be2 /vl.c
parentddcc8e9d51c415a7b7b2983c3552408d9a50be6e (diff)
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 'vl.c')
0 files changed, 0 insertions, 0 deletions