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

[Mark McLoughlin]

Hi Dan,

Looks great overall

On Thu, 2009-12-10 at 22:22 +0000, Daniel P. Berrange wrote:

> I then remembered that for support NIC/VirtIO/hostdev disk unplug
> Mark M had previously added PCI address information to the internal
> XML state files for <interface>, <disk> and <hostdev> elements.

Note, the devaddr property in the state file only had domain/bus/slot
since there was no multi-function devices involved.

Also, we should try to handle translating the devaddr state to <address>
config - e.g. if you upgrade libvirt while a guest is running with a
hotplugged device

> libvirt itself will auto-assign all drive addresses, and QEMU
> will auto-assign PCI adresses in dynamic mode. When starting
> a guest VM we run 'info pci' to get a list of PCI vendor/product
> IDs and matching PCI addresses. We then attempt to match those
> up with the devices we specified to QEMU. It sounds nasty, but
> it actually works fairly well. This means we also now make it
> possible to hotunplug any device, even those the VM was initially
> booted with

Glad to hear this works well

> There is one small issue with all this, we need to know every
> PCI device in the guest. It turns out there are a handful of
> devices in QEMU we don't represent in XML yet
> 
>  - Virtio balloon device
>  - Virtio console (this is easy to address with matt's patches)
>  - ISA bridge
>  - USB controller
>  - Some kind of PCI bridge (not clear what this is, it has
>    PCI ID 8086:7113
> 
> If an management application is to be able to fully control
> static PCI addressing, we need to represent these somehow,
> so apps can give them addresses. Technically we could get
> away with not representing the ISA/PCI bridge since QEMU
> always gives them the first PCI slot no matter what. Still
> need the VirtIO & USB devices dealt with.

When we discussed this on qemu-devel, we thought it made sense to only
expose "free slots" information to the higher levels - i.e. all the
management app cares about is what slots are available for address
allocation, not what is in the used slots. It also means the management
apps doesn't need to know e.g. how many PCI slots there are per bus.

Cheers,
Mark.