Andrea had the right idea when he disabled the "reserve an extra
unused slot" bit for aarch64/virt. For *any* PCI Express-based
machine, it is pointless since 1) an extra legacy-PCI slot can't be
used for hotplug, since hotplug into legacy PCI slots doesn't work on
PCI Express machinetypes, and 2) even for "coldplug" expansion,
everybody will want to expand using Express controllers, not legacy
PCI.

This patch eliminates the extra slot reserve unless the system has a
pci-root (i.e. legacy PCI).
---
 src/qemu/qemu_domain_address.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 83e3861..1ff80e3 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1713,16 +1713,17 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
                 buses_reserved = false;
         }
 
-        /* Reserve 1 extra slot for a (potential) bridge only if buses
-         * are not fully reserved yet.
+        /* Reserve 1 extra slot for a (potential) bridge (for future
+         * expansion) only if buses are not fully reserved yet.
          *
-         * We don't reserve the extra slot for aarch64 mach-virt guests
-         * either because we want to be able to have pure virtio-mmio
-         * guests, and reserving this slot would force us to add at least
-         * a dmi-to-pci-bridge to an otherwise PCI-free topology
+         * We only do this for those domains that have pci-root, since
+         * those with pcie-root will usually want to expand using PCIe
+         * controllers, and we don't want to saddle all PCIe domains
+         * down with a dmi-to-pci-bridge *and* a pci-bridge when they
+         * will probably never use it.
          */
         if (!buses_reserved &&
-            !qemuDomainMachineIsVirt(def) &&
+            qemuDomainMachineHasPCIRoot(def) &&
             qemuDomainPCIAddressReserveNextSlot(addrs, &info) < 0)
             goto cleanup;
 
-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to