]> git.ipfire.org Git - thirdparty/libvirt.git/commit
qemu: auto-assign hostdev devices to PCIe
authorLaine Stump <laine@redhat.com>
Wed, 17 Jun 2020 20:18:23 +0000 (16:18 -0400)
committerLaine Stump <laine@redhat.com>
Thu, 25 Jun 2020 03:26:42 +0000 (23:26 -0400)
commit8c6dba054b012ad3d71bccc5b25cf297681d81d3
tree6b8c5fad0b75e7778fafe164e98b1fa03b273117
parentd66f2be2ab0233f5b1648cd0bf539feb4aefd9b8
qemu: auto-assign hostdev devices to PCIe

Until recently, an <interface type='network'> would automatically be
assigned model "rtl8139", which in turn would lead to the device being
assigned a PCI address on a conventional PCI controller (i.e. a
pcie-to-pci-bridge). If the network was a typical Linux host
bridge-based network that used an emulated device, this would be
appropriate, since the guest actually would get an emulated rtl8139
NIC, and that device is a conventional PCI device.

However, if the network being used was a pool of hostdev devices, the
guest would get an actual PCIe network device assigned from the host
via VFIO; while the interface model in that case is irrelevant for the
QEMU commandline to assign the device, the PCI address would have
already been assigned prior to runtime, so the address assignment
would be done based on the model='rtl8139' - a conventional PCI
device. VFIO assignment of a PCIe device to a conventional PCI slot
works, but we would rather have these devices in a PCIe slot.

Since commit bdb8f2e4186, if <interface type='network'> points to a
etwork that is a pool of hostdev devices, the interface model will be
_unset_ by default. This patch uses that information when deciding
what type of slot to assign to the device: since all hostdev network
interfaces are SR-IOV VFs, and *all* SR-IOV network cards are PCIe, it
is safe to assume that the VFs are PCIe and we should assign then to a
PCIe slot in the guest.

Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
src/qemu/qemu_domain_address.c