[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RESEND v2 1/3] pc: Set hw_version on all machine
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH RESEND v2 1/3] pc: Set hw_version on all machine classes |
Date: |
Tue, 10 Nov 2015 15:30:27 -0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Mon, Nov 09, 2015 at 10:45:17PM +0200, Michael S. Tsirkin wrote:
> On Fri, Oct 30, 2015 at 05:36:07PM -0200, 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.
> >
> > Reported-by: Laszlo Ersek <address@hidden>
> > Reviewed-by: Laszlo Ersek <address@hidden>
> > Signed-off-by: Eduardo Habkost <address@hidden>
>
> Ouch.
>
> I really don't want even more churn with each version.
>
> Can't we use the name supplied to DEFINE_PC_MACHINE at least for future
> machine types?
>
> Or maybe we should stop exposing the version to guests - does it really
> have any value given it has been so unreliable historically?
I'm all for stopping exposing it to guests. This is where we expose it,
currently:
hw/arm/nseries.c: pstrcat((void *) w, 12, qemu_hw_version()); /* char
version[12] */
hw/ide/core.c: pstrcpy(s->version, sizeof(s->version),
qemu_hw_version());
hw/scsi/megasas.c: snprintf(info.package_version, 0x60, "%s-QEMU",
qemu_hw_version());
hw/scsi/scsi-bus.c: pstrcpy((char *) &r->buf[32], 4, qemu_hw_version());
hw/scsi/scsi-disk.c: s->version = g_strdup(qemu_hw_version());
target-i386/cpu.c: qemu_hw_version());
>
> How about:
>
> ---
>
> diff --git a/util/osdep.c b/util/osdep.c
> index 0092bb6..4dc635d 100644
> --- a/util/osdep.c
> +++ b/util/osdep.c
> @@ -52,7 +52,7 @@ extern int madvise(caddr_t, size_t, int);
>
> static bool fips_enabled = false;
>
> -static const char *qemu_version = QEMU_VERSION;
> +static const char *qemu_version = "QEMU";
This would lead to stuff like "QEMU virtual CPU version QEMU", and
OMAP_TAG_VERSION_STR/hw-build set to "QEMU QEMU" on nseries. I believe
we must first change the IDE, SCSI and CPUID code to stop using
qemu_hw_version() on new machine-types.
After that, we could even make qemu_hw_version() call abort() on newer PC
machine-types (meaning only the old machines would be allowed to use it, to
keep compatibility).
--
Eduardo