Re: [libvirt] [PATCH v4 4/4] auto-create pci-bridge controller info

On 03/04/2013 11:51 AM, Ján Tomko wrote: 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)? 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. 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) 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. 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.