From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvtJe-0004By-Ev for qemu-devel@nongnu.org; Mon, 09 Nov 2015 15:45:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvtJa-0005P0-DO for qemu-devel@nongnu.org; Mon, 09 Nov 2015 15:45:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvtJa-0005Ov-7j for qemu-devel@nongnu.org; Mon, 09 Nov 2015 15:45:22 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id AC5C4BBDD for ; Mon, 9 Nov 2015 20:45:21 +0000 (UTC) Date: Mon, 9 Nov 2015 22:45:17 +0200 From: "Michael S. Tsirkin" Message-ID: <20151109222208-mutt-send-email-mst@redhat.com> References: <1446233769-7892-1-git-send-email-ehabkost@redhat.com> <1446233769-7892-2-git-send-email-ehabkost@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1446233769-7892-2-git-send-email-ehabkost@redhat.com> Subject: Re: [Qemu-devel] [PATCH RESEND v2 1/3] pc: Set hw_version on all machine classes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Paolo Bonzini , Laszlo Ersek , qemu-devel@nongnu.org, Marcel Apfelbaum 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 > Reviewed-by: Laszlo Ersek > Signed-off-by: Eduardo Habkost 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: --- 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"; int socket_set_cork(int fd, int v) {