Re: [Qemu-devel] Versioned machine types for ARM/non-x86 ? (Was Re: [PATCH v4 0/2] ARM: add 'virt' platform)

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Aug 05, 2013 at 08:28:50AM -0500, Anthony Liguori wrote:
> "Daniel P. Berrange" <berrange@redhat.com> 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 :|