[libvirt] [PATCH 0/12] Standardized device addressing & SCSI controller/disk hotplug

[Mark McLoughlin]

On Thu, 2009-12-17 at 09:39 +0000, Daniel P. Berrange wrote:
> On Thu, Dec 10, 2009 at 10:22:20PM +0000, Daniel P. Berrange wrote:
> > The XML for each address type looks like
> > 
> >       <address type='pci' mode='static' domain='0x0000' bus='0x1e' slot='0x07' function='0x0'/>
> >       <address type='usb' mode='dynamic' bus='007' dev='003'/>
> >       <address type='drive' mode='dynamic' controller='1' bus='0' unit='5'/>
> > 
> > 
> > The 'mode' attribute for any of them is allowed to be either
> > 'static' or 'dynamic'. A static address is one specified by
> > the end user when defining the XML, while a dynamic address is
> > one automatically chosen by libvirt/QEMU every time a guest
> > boots. The idea of static addresses is to allow management
> > apps to guarentee that PCI device & drive numbering never
> > changes. This series does not actually implement static
> > addressing for PCI yet, because it requires that we change
> > the way we generate QEMU command line arguments. It does
> > do static addressing for disks.
> 
> I'm now wondering whether we actually truely need the 'dynamic'
> option. It already doesn't really make sense for disks. For PCI
> though I'm not sure anyone would ever want the dynamic mode, 
> where addresses can change at every boot. I think I should just
> remove the 'mode' attribute here, and just have libvirt detect
> PCI addresses the first time, and keep them the same thereafter.

Just reading the proposal now and this is the bit that jumps out at me
most. I don't think we need the dynamic/static mode split.

For PCI, we really want to just automatically remember assigned PCI
addresses and use them forever after - I don't see any obvious use case
where you wouldn't want this.

Also, it strikes me that we've done this before - e.g. if you define a
guest with an interface with no explicit MAC address, we generate one
and save it in the config. Which is pretty much the same thing from the
users point of view.

> The second thought is whether we should put the <address>
> data inside a <device> element, so it looked like
> 
>   <device type='pci'>
>      <address domain='0x0000' bus='0x1e' slot='0x07' function='0x0'/>
>   </device>
> 
> The reason being, that I think it might be interesting to  also add in
> the vendor / product info at a later date 
> 
>   <device type='pci'>
>      <vendor id='0x8086'/>
>      <product id='0x1234'/>
>      <address domain='0x0000' bus='0x1e' slot='0x07' function='0x0'/>
>   </device>

Dunno, it seems odd to have:

  <devices>
    <interface>
      <device>

I read that as "<devices> is a list of device objects", "<interface> is
a specialization of the device class" ... "wtf is <device> then?"

I guess it makes some sense as a container of device information common
to all device types, though.

Cheers,
Mark.