Re: [libvirt] [PATCH v4 4/4] auto-create pci-bridge controller info
On 03/04/13 20:39, Laine Stump wrote:
On 03/04/2013 11:51 AM, Ján Tomko wrote:
> This will only add bridges for the explictly mentioned buses, which
> would mean we could have buses 0 and 6 with no buses between them.
> Maybe we should add them the way we add disk controllers - find the
> highest index and add all bridges with indexes from 1 to max.
But each pci bridge device takes up another slot, which we may not want
to give up. (Although arguably, once we have pci-bridge devices, we can
create as many slots as we like :-)
Is there some advantage to having all the buses filled in (other than
similarity to what's done for other types of controllers)?
The only thing I can think of is that the PCI addresses in the XML
config will match those that can be seen in the guest.
> It would be nice if we could add pci bridges even when there
weren't any
> specified in the XML, but there are too many PCI devices. I don't know
> what would be the nicest way to do that.
If we auto-assign addresses for un-addressed devices first (your recent
patches did that, right? I forget the status of those), *then*
auto-create the required bridges (which themselves will need an
auto-assigned address), that should just happen.
My first (1/2) patch (pushed already) changed the function parameters to
use the PCI address struct instead of just slot and function and it did
not change any functionality.
I still need to post another version of 2/2, which should make the
allocation of addresses with bus > 0 possible.
Of course, if we do that, then we won't have reserved any slots on bus 0
for even a single pci-bridge device, so we'll fail. Is the proper way
out of this to always reserve one (or maybe two, for good measure) slots
on any given bus to be used only for bridges? That way no matter how out
of hand things get, we'll always have a place we can add another bus.
(In the case of *lots* of devices, I assume that a device on a nested
PCI bridge would be less efficient, and may have some other limitations,
but it would be better than nothing. And if the admin was really
concerned about that, they could modify their config to explicitly place
several bridges directly on bus 0)
So when searching for a new slot (when multiple buses are enabled), we
would for example stop at slot 29 and only look at 30 and 31 for bridges?
The only other way I can think of is assign the addresses twice, the
first time only to see how many bridges we need. But this won't work for
hotplug.
This also brings up the fact that we need to deal with the possibility
of all buses being full during hotplug - when that happens I suppose we
will also want to auto-add a pci bridge.
Hmm. This would require the address allocation function to know how many
buses we have and go through all of them. It seems we wouldn't need to
do that for the initial allocation - when we get to the end of the bus,
we know it's full.
> Maybe Peter's patches for
> config parser defaults will be helpful:
> https://www.redhat.com/archives/libvir-list/2013-March/msg00042.html
A circular reference of data definitions led to danpb saying that this
is probably the wrong way to do it, so it looks like it will require
some rework, but definitely whatever shape that takes, this code will
want to fit into that framework.
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list