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.
Cheers,
Mark.
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list