There is a very slight time advantage to beginning the search for the next unused PCI address at the slot *after* the previous find (which is now used), but if we do that, we will miss allocating the other functions of the same slot (when we implement a VIR_PCI_CONNECT_AGGREGATE_SLOT flag to support that). --- src/conf/domain_addr.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c index 62f60d3..29d06f1 100644 --- a/src/conf/domain_addr.c +++ b/src/conf/domain_addr.c @@ -690,18 +690,14 @@ virDomainPCIAddressGetNextSlot(virDomainPCIAddressSetPtr addrs, } /* ...unless this search is for the exact same type of device as - * last time, then continue the search from the next slot after - * the previous match (the "next slot" may possibly be the first - * slot of the next bus). + * last time, then continue the search from the slot where we + * found the previous match (it's possible there will still be a + * function available on that slot). */ - if (flags == addrs->lastFlags) { + if (flags == addrs->lastFlags) a = addrs->lastaddr; - if (++a.slot > addrs->buses[a.bus].maxSlot && - ++a.bus < addrs->nbuses) - a.slot = addrs->buses[a.bus].minSlot; - } else { + else a.slot = addrs->buses[0].minSlot; - } /* if the caller asks for "any function", give them function 0 */ if (function == -1) -- 2.7.4 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list