launch-libvirt: place our virtio-net-pci device in slot 0x1e

The <qemu:commandline> trick we use for adding our virtio-net-pci device
in the libvirt backend can conflict with libvirtd's and QEMU's PCI address
assignment. Try to mitigate that by placing our device in slot 0x1e on the
root bus. In practice this could only conflict with a "dmi-to-pci-bridge"
device model, which libvirtd itself places in slot 0x1e. However, given
the XMLs we generate, and modern QEMU versions, libvirtd has no reason to
auto-add "dmi-to-pci-bridge". Refer to
<https://libvirt.org/formatdomain.html#controllers>.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2034160
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20211223103701.12702-2-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>

lib/guestfs-internal.h

@@ -172,6 +172,17 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr)
 #define VIRTIO_DEVICE_NAME(type) type "-pci"
 #endif
 
+/* Place the virtio-net controller in slot 0x1e on the root bus, on normal
+ * hardware with PCI. Refer to RHBZ#2034160.
+ */
+#ifdef HAVE_LIBVIRT_BACKEND
+#if defined(__arm__) || defined(__s390x__)
+#define VIRTIO_NET_PCI_ADDR ""
+#else
+#define VIRTIO_NET_PCI_ADDR ",addr=1e.0"
+#endif
+#endif
+
 /* Guestfs handle and associated structures. */
 
 /* State. */

lib/launch-libvirt.c

@@ -1851,7 +1851,9 @@ construct_libvirt_xml_qemu_cmdline (guestfs_h *g,
       } end_element ();
 
       start_element ("qemu:arg") {
-        attribute ("value", VIRTIO_DEVICE_NAME ("virtio-net") ",netdev=usernet");
+        attribute ("value", (VIRTIO_DEVICE_NAME ("virtio-net")
+                             ",netdev=usernet"
+                             VIRTIO_NET_PCI_ADDR));
       } end_element ();
     }