[RESEND,v2,1/3] pc: Set hw_version on all machine classes

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 <lersek@redhat.com>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>

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?

How about:

---

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 <lersek@redhat.com>
> > Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> 
> 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).