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

[Mark McLoughlin]

On Sun, 2009-05-31 at 17:47 +0300, Dor Laor wrote:
> Mark McLoughlin wrote:
> > On Fri, 2009-05-29 at 10:43 +0100, Mark McLoughlin wrote:
> >
> >   
> >> 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.
> >>     
> >
> > Okay, how about this:
> >
> >   - Add a saveabi monitor command
> >
> >   - Whenever libvirt starts a guest or hotplugs a device, it executes
> >     saveabi and retains the output
> >
> >   - The abi can be restored with qemu -loadabi or the loadabi monitor 
> >     command
> >
> >   - The abi file doesn't describe the device model, it merely gives 
> >     hints for building the device model which is described on the
> >     command line
> >
> >   - If the abi file contains details of a device which is not listed on 
> >     the command line, it's just ignored and not included in the next 
> >     saveabi
> >
> >   - If the abi file is missing details of a device which is listed on 
> >     the command line, the device is constructed using the defaults and 
> >     included in the next saveabi
> >
> >   - This means the abi file is opaque to the management tools - unlike 
> >     the machine config file, libvirt would not need to modify it when
> >     devices are added or removed by the user
> >   
> IMO it shouldn't be opaque

The important requirement is that management tools should never need to
modify saveabi output.

> and we might use the same config file for the abi too.

What we don't want is:

  $> qemu -config guest.config

where guest.config contains both details of which devices are needed
*and* what their ABI should be.

We want:

  $> qemu -loadabi guest.abi -config guest.confg

or:

  $> qemu -loadabi guest.abi -drive ... -net ... -serial ...

The idea being that we should not mix up ABI requirements with device
configuration.

The management tools do not need to know the details of the ABI
provided, they just want to request qemu to use the same ABI as was used
previously.

Put more simply - with saveabi/loadabi, the management tools would not
need to know that older versions of qemu's virtio-console used
PCI_CLASS_DISPLAY_OTHER.

> The notion of abi config is indeed required and most of the times, mgmt 
> tools won't need to deal with it.
> 
> But, let's say for instance that the user with certain abi configs, now 
> change some existence of pci device, bios memory mapping, etc. In the
> case mgmt should automatically adjust both config files to minimize
> the effect on the guest and not to create a conflict.

I think that would defeat a lot of the value of this. It adds an awful
lot of complexity to the management tools.

The device config file should always just take precedence and the abi
file should just be used as hints to allow the same ABI to be used. If
e.g. a device is removed, the hints for that device can be ignored and
dropped in the next saveabi.

Cheers,
Mark.