qemu-devel
[Top][All Lists]
Advanced

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

Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13]


From: Mark McLoughlin
Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]
Date: Fri, 12 Jun 2009 18:31:23 +0100

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]