On 03/06/2013 10:23 AM, Daniel P. Berrange wrote: > On Wed, Mar 06, 2013 at 04:15:28PM +0100, Ján Tomko wrote: >> On 03/05/13 11:36, Daniel P. Berrange wrote: >>> On Mon, Mar 04, 2013 at 02:39:40PM -0500, Laine Stump wrote: >>>> On 03/04/2013 11:51 AM, Ján Tomko wrote: >>>>> 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. >>>> >>>> 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) >> Maybe we could reserve the first bus as well? I'm guessing that putting things behind a bridge might reduce performance somewhat? (or maybe it's a completely artificial concept within qemu that only exists for the sake of making things look right to the guest, I just don't know) > I don't think we should artifically reserve anything that isn't > absolutely required by the underlying machine type. Yeah, I don't think we should reserve an entire bus. However, when auto-assigning slots, I think we should make a "best effort" to always leave at least one slot open at the end. This will ensure that anyone hotplugging bunches of devices with no explicit pci address will succeed (although their final topology may be suboptimal). >>> You'd have todo a 2 pass assignment. First count the number of devices >>> that need to have PCI addresses assigned. Then create the required >>> number of bridges, then assign the addresses. >>> >> Which one is better? The reserved slots would make auto-adding bridges >> on hotplug possible, but I fear the code would be too ugly. On the other >> hand, 2-pass assignment sounds really easy to do :) > I think we just do the 2-pass auto-assignment. As long as the auto-assignment always finishes with at least one slot open, and we also do the same 2-pass scan when hotplugging a single device, then I think everybody is satisfied (basically it will scan and find that one device (the new one) doesn't have an address assigned, but when it counts it will discover that assigning that address on an existing bus will exhaust all slots, so it will add a new bus (which will be placed into the single remaining slot), then do the 2nd pass which will place the new device on the new bus.) If someone explicitly assigns device addresses such that all available slots are taken up (leaving no room for future expansion), then they've dug their own grave (or know what they're doing) and there's nothing we can do about it. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list