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

On Fri, 2009-12-18 at 14:32 +0000, Daniel P. Berrange wrote: > Actually I think I've been thinking about dynamic vs static at the wrong > level. It isn't something that needs to be considered per device. It is > a property of the QEMU version the guest runs, and we can figure that out > at time of define. > > - For QEMU >= 0.12, all devices support static PCI addressing, so we > can easily assign all PCI addrs at time of virDefineXML and this > address info gets saved to disk. How would you do the address allocation in libvirt? Would you start qemu and query which addresses have been assigned already? Would you have knowledge in libvirt about e.g. how many devices can be assigned to a bus?

> - For QEMU < 0.12, no devices support static PCI addressing, so we will > always query for assigned PCI addrs at time of startup and have no > need to ever save this info to disk, since the QEMU doesn't support > static addressing It'd be nice to remember the assigned addresses for a 0.11 guest so that when the host is upgraded to 0.12 we can request the same addresses that were used when running on 0.11.

> At most we need to indicate in the capabilities XML that a guest type > supports PCI addressing, merely as a piece of useful info for PCI. They > would never have to actually set any PCI addrs themselves. You've kind of lost me here. From the API user's point of view, there are two ways you might want this handled: 1) Don't specify a device address in the guest config, but whatever address ultimately gets assigned is then stored in the guest config so that it never changes I don't see that it matters so much when the address assignment happens - e.g. it could be assigned at 'define' or assigned at 'start' - all that matters is once the guest OS has seen the device assigned at that address, then the address shouldn't change thereafter 2) Obtain information on what addresses are available for assignment and assign an address to a device before attaching it to the guest config Personally, I don't think this is terribly useful and I'm not sure we're totally clear on the real details of the use case - e.g. we could have a "give me an unallocated address of type 'PCI'" API, but why would someone use that instead of (1). We could have a "give me a list of of available slots for bus Y" API, but if we were e.g. going to have a PCI specific dialog in virt-manager for arranging the PCI topology, maybe it's fine for virt-manager to have a load of PCI specific knowledge. So, I think we're really just talking about (1), but it's a question of whether libvirt should allow qemu to allocate addresses, or have libvirt itself allocate them.

I think it's easier to just allow qemu allocate the addresses and have libvirt query the result. But this means changing the guest config at 'start', which you're saying we should avoid. (Why?)

If libvirt does the address assignment itself at 'define', I guess we only have two fairly minor problems - a) making sure the allocation scheme is safe against future qemu changes and b) not being able to have address for guests created on a host with < 0.12.