Thread (1 message) 1 message, 1 author, 2009-06-12

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

From: Blue Swirl <hidden>
Date: 2009-06-12 17:44:41

On 6/12/09, Mark McLoughlin [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help