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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
