Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER

[Mark McLoughlin <markmc@redhat.com>]

On Fri, 2009-05-29 at 00:45 +0300, Dor Laor wrote:

> Nevertheless, as Anthony states, guest ABI should be rock stable.
> We should have mechanism (machine conf format++) that will enable us
> to configure pci addresses, cpuid entries, memory layout, device 
> existence (hpet, virtio-console,..), etc.
> 
> Anyhow, I did sent a patch to allow virtio block to parametrized class 
> value -
> http://lists.gnu.org/archive/html/qemu-devel/2009-05/msg01189.html
> There wasn't a perfect match with finding the right interface to change 
> it, happy to hear
> other alternatives if you're not happy with it.

As I said, it's pointless to add something like this if, realistically,
it will never be used.

So, taking the example of '-drive class=foo' ... a user who runs qemu
directly would have to know that when she updates from qemu-0.10.x to
qemu-0.11.x, she needs to use '-drive class=384' for ever more. I find
it hard to believe anyone will ever do that.

Perhaps management tools can hide this complexity? In order to do this
in libvirt, we'd need to do the following:

  1) Add a 'pci_class' property to <device><target>:

    <disk type='file' device='disk'>
      <source file='foo.img' format='raw'/>
      <target dev='vda' bus='virtio' pci_class='384'/>
    </disk>

  2) If a guest's configuration does not contain the pci_class
     property, then once the guest is running, parse the output of 'info
     pci', somehow map each disk to a PCI address, map the class 
     descriptions to class numbers and save the class to the guests 
     configuration.

  3) If a given qemu binary supports '-drive class=', then pass it the 
     class value on startup, if configured

  4) Require users to update to libvirt and run the guest at least once 
     with the old version of qemu, before updating to the new version 
     of qemu

Assuming this is actually possible to implement (see "somehow" in step
2), I doubt anyone would ever be bothered enough to implement it.

Anthony's suggestion of a way to list device properties would help a
little in theory, but in practice the old qemu binary wouldn't have this
command so libvirt would have no way of finding this class=384 value.

A machine configuration format (even assuming a command to dump the
configuration of a guest) doesn't help much more, for the same reason.

And none of this solves the problem that management tools have to play
catch up - they cannot predict how we will change the ABI, so users have
to update to a newer version of the management tools with code to
support the ABI change *before* updating qemu.

The more I think about it, no matter how much linear ABI versioning
sucks, it's possibly the only way to solve this in a reasonably usable
manners. Distros would just have to suck it up and agree that if they
cherry-pick an ABI changing patch, they must update the entire ABI to
the newer upstream ABI version.

Cheers,
Mark.