This bug still seems to be present in Trixie. Looking at the contents of the libvirt-<uuid>.files which is generated by libvirt, it's missing the necessary PCI permissions when an SR-IOV virtual function is assigned via a network instead of via a static PCI device address.
Specifically in this case, the following are missing from the permissions file:
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.1/resource3" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.1/vendor" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.1/reset" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.1/resource" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.1/device" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.1/resource0" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.1/config" rw,
"/dev/vfio/vfio" rw,
"/dev/vfio/[0-9]*" rw,
but the following is erroneously present:
"/dev/vhost-net" rw,
VM definition fragment which produces the behaviour:
<interface type='network'>
<mac address='52:54:00:e9:4b:bc'/>
<source network='i350port1passthrough'/>
<address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
</interface>
Network definition:
<network>
<name>i350port1passthrough</name>
<uuid>389297b8-0f92-4523-9ad8-5d633cdddccf</uuid>
<forward mode="hostdev" managed="yes">
<pf dev="envftest"/>
</forward>
</network>
Assigning via the pool is desirable because the PCIe devices are dynamically assigned, so the bus slot assignments etc. are not guaranteed to persist. Additionally live migration can fail unless the PCI device addresses are identical on the source and destination hardware.
More details can be found in e.g. this article:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-pci_devices-pci_passthrough#sect-PCI_devices-PCI_passthrough
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)