On Tue, Sep 22, 2015 at 10:26:14PM +0200, Laszlo Ersek wrote: > On 09/22/15 22:16, Eduardo Habkost wrote: > > 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. > > > > Signed-off-by: Eduardo Habkost <ehabk...@redhat.com> > > --- [...] > > Can you please add: > > Reported-by: Laszlo Ersek <ler...@redhat.com> > > to this patch? (If you agree, that is.)
Of course! :) (Sorry, while trying to finish and submit the series before the end of the day, I forgot to give you credit for finding this 3-year-old bug) > > Other than that, while I'm sure you'll need (and get) other reviews too: > > Reviewed-by: Laszlo Ersek <ler...@redhat.com> Thanks! -- Eduardo
