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

[Anthony Liguori <aliguori@us.ibm.com>]

"Daniel P. Berrange" <berrange@redhat.com> writes:

> 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 ?

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 :|