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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux