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. > >> NB the device tree contains no host configuration information. > >> > > > > So, it wouldn't e.g. include the path to the image file for a block > > device? That would always be specified on the command line? > > > > No, the IDE definition would contain some sort of symbolic node name. A > separate mechanism (either command line or host config file) would then > link a image file to the symbolic name. Okay. > libvirt should really never worry about the machine config file for > normal things unless it needs to change what devices are exposed to a guest. But changing devices *is* normal ... e.g. removing a block device. Writing out a device tree is not a problem for libvirt (or any other management tools), it's the need to merge changes into an existing device tree is where the real complexity would lie. Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
