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

[Laine Stump]

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.