Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]

[Blue Swirl]

On 6/12/09, Mark McLoughlin <address@hidden> wrote:
> On Fri, 2009-06-12 at 12:00 -0500, Anthony Liguori wrote:
>  > Mark McLoughlin wrote:
>  > > So, when libvirt creates a guest for the first time, it makes a copy of
>  > > the device tree and continues to use that even if qemu is upgraded.
>  > > That's enough to ensure compat is retained for all built-in devices.
>  > >
>  > > However, in order to retain compat for that SCSI device (e.g. ensuring
>  > > the PCI address doesn't change as other devices are added an removed),
>  > > we're back to the same problem ... either:
>  > >
>  > >   1) Use '-drive file=foo.img,if=scsi,pci_addr=foo'; in order to figure
>  > >      out what address to use, libvirt would need to query qemu for what
>  > >      address was originally allocated to device or it would do all the
>  > >      PCI address allocation itself ... or:
>  > >
>  > >   2) Don't use the command line, instead get a dump of the entire
>  > >      device tree (including the SCSI device) - if the device is to be
>  > >      removed or modified in future, libvirt would need to modify the
>  > >      device tree
>  > >
>  > > The basic problem would be that the command line config would have very
>  > > limited ability to override the device tree config.
>  > >
>  >
>  > After libvirt has done -drive file=foo... it should dump the machine
>  > config and use that from then on.
>
>  Right - libvirt then wouldn't be able to avoid the complexity of merging
>  any future changes into the dumped machine config.
>
>  > To combined to a single thread...
>  > > How do you add a new attribute to the device tree and, when a supplied
>  > > device tree lacking said attribute, distinguish between a device tree
>  > > from an old version of qemu (i.e. use the old default) and a partial
>  > > device tree from the VM manager (i.e. use the new default) ?
>  > >
>  >
>  > Please define "attribute".  I don't follow what you're asking.
>
>  e.g. a per-device "enable MSI support" flag.
>
>  If qemu is supplied with a device tree that lacks that flag, does it
>  enable or disable MSI?
>
>  Enable by default is bad - it could be a device tree dumped from an old
>  version of qemu, so compat would be broken.
>
>  Disable by default is bad - it could be a simple device tree supplied by
>  the user, and the latest features are wanted.
>
>  Maybe we want a per-device "this is a complete device description" flag
>  and if anything is missing from a supposedly complete description, the
>  old defaults would be used. A config dumped from qemu would have this
>  flag set, a config generated by libvirt would not have the flag.

If the device has different behavior or different properties from
guest perspective compared to the old device, it should get a new
device type so that you could specify in the device tree either the
old device or the new one. Flags won't help in the long term.