From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6LWH-0002uW-ME for qemu-devel@nongnu.org; Mon, 05 Aug 2013 10:12:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6LWC-0001w5-3k for qemu-devel@nongnu.org; Mon, 05 Aug 2013 10:12:21 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:53953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6LWC-0001vw-04 for qemu-devel@nongnu.org; Mon, 05 Aug 2013 10:12:16 -0400 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 5 Aug 2013 10:12:15 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 63EA938C804D for ; Mon, 5 Aug 2013 10:12:10 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r75ECB9Q113786 for ; Mon, 5 Aug 2013 10:12:11 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r75ECBLZ016364 for ; Mon, 5 Aug 2013 10:12:11 -0400 From: Anthony Liguori In-Reply-To: <20130805134915.GE5108@redhat.com> References: <1375701492-21759-1-git-send-email-peter.maydell@linaro.org> <20130805124922.GA5108@redhat.com> <87ob9cz2p9.fsf@codemonkey.ws> <20130805134915.GE5108@redhat.com> Date: Mon, 05 Aug 2013 09:12:02 -0500 Message-ID: <87y58gp6q5.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] Versioned machine types for ARM/non-x86 ? (Was Re: [PATCH v4 0/2] ARM: add 'virt' platform) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Peter Maydell , "Mian M. Hamayun" , patches@linaro.org, Markus Armbruster , qemu-devel@nongnu.org, kvmarm@lists.cs.columbia.edu "Daniel P. Berrange" writes: > On Mon, Aug 05, 2013 at 08:28:50AM -0500, Anthony Liguori wrote: >> "Daniel P. Berrange" writes: >> >> > On Mon, Aug 05, 2013 at 12:18:10PM +0100, Peter Maydell wrote: >> >> This patch series adds a 'virt' platform which uses the >> >> kernel's mach-virt (fully device-tree driven) support >> >> to create a simple minimalist platform intended for >> >> use for KVM VM guests. It's based on John Rigby's >> >> patches, but I've overhauled it a lot: >> > >> > On x86, we've long had versioned machine names, so that we can >> > make changes in future QEMU releases without breaking guest ABI >> > compatibility. AFAICT, the problem has basically been ignored >> > on non-x86 platforms in QEMU. Given the increased interest in >> > ARM in particular, should we use the addition of this new 'virt' >> > machine type, as an opportunity to introduce versioning for >> > ARM too. eg make this machine be called 'virt-1.0.6' and then >> > have 'virt' simply be an alias that points to the most recent >> > version. >> >> I've been thinking about this for SPAPR too. Like virt, I'm not sure >> the platform is stable enough for this but I expect it to be soon. > > BTW, do you have any tests / scripts you use to validate the machine > type stability prior to cutting releases ? I use qemu-test which has a finger printing test for this purpose. > > Seems like it ought to be able to have some custom initrd which > just recorded contents of various sysfs/procfs files & perhaps PCI > device config space blobs. That's exactly what it does in fact. > Then just boot the QEMU release candidate > binaries with this initrd & compare the results to previously recorded > data, for each machine type ? If the records for each machine type > were checked into GIT, you could arguably do this as part of 'make test' > so developers can see if something they're doing is breaking ABI by > mistake. > >> However, unlike PC, I'd like to do linear versioning and avoid bumping >> at every release. >> >> IOW, spapr-1, spapr-2, spapr-3, etc. >> >> I think virt ought to try to do the same. > > Any particular reason why ? I kind of like the clarity of having the > version match the release version. Avoids needing to lookup a magic > decoder ring to figure out which QEMU version maps to which machine > version. (1) reduces testing matrix by having fewer versions (2) makes people think more carefully about whether it's really necessary to break compatibility. > Would you say that stable release branches should not accept any > patch that changes guest ABI, to avoid this single component version > number turning into a 2 component version on stable branches ? Yes. This is already the policy FWIW. Regards, Anthony Liguori > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|