From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6L9s-0001bI-LH for qemu-devel@nongnu.org; Mon, 05 Aug 2013 09:49:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6L9n-0000sW-8n for qemu-devel@nongnu.org; Mon, 05 Aug 2013 09:49:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6L9n-0000sP-0S for qemu-devel@nongnu.org; Mon, 05 Aug 2013 09:49:07 -0400 Date: Mon, 5 Aug 2013 14:49:16 +0100 From: "Daniel P. Berrange" Message-ID: <20130805134915.GE5108@redhat.com> References: <1375701492-21759-1-git-send-email-peter.maydell@linaro.org> <20130805124922.GA5108@redhat.com> <87ob9cz2p9.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87ob9cz2p9.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] Versioned machine types for ARM/non-x86 ? (Was Re: [PATCH v4 0/2] ARM: add 'virt' platform) Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , "Mian M. Hamayun" , patches@linaro.org, Markus Armbruster , qemu-devel@nongnu.org, kvmarm@lists.cs.columbia.edu 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 ? 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. 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. 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 ? 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 :|