Hi Alex,
Thanks for the explanation! What a pity but I will workaround by
manually assigning VFs.
The emulation based approach is also interesting but seems requiring
much efforts. I'm happy to see it (eventually) being implemented someday.
Thanks,
Tydus
On 2022/6/4 0:51, Alex Williamson wrote:
On Fri, 3 Jun 2022 23:13:39 +0900
Tydus <ty...@hongo.wide.ad.jp> wrote:
Hi list,
I'm trying to passthrough an SR-IOV capable device (PF) into a VM and
make it spawn VFs into it and had no luck.
Digging into qemu vfio code I found
https://github.com/qemu/qemu/commit/e37dac06dc4e85a2f46c24261c0dfdf2a30b50e3
which gives me some insights about the situation at that time. However I
wonder if this situation had changed since. It seems vIOMMU has been
implemented and VFIO adds SR-IOV support these years (but it might be
not related).
Sorry if I'm wrong but I'm not that familiar with VFIO and PCIE
internals. Any help or information is appreciated.
Hi Tydus,
It's a common misconception that a VM owned PF can enable SR-IOV and
the VFs will simply appear in the VM. This is not how PCI device
assignment works. The PF is virtualized into the VM and VF devices
created by the PF must also be created on the host and virtalized into
the VM. The kernel vfio-pci driver has support for enabling SR-IOV, but
the QEMU and above stack does not. Effectively a VM interaction with
the PF SR-IOV capability would need to be trapped and signaled to a
management tool like libvirt to perform the SR-IOV configuration in the
host, after which the new host VFs would be collected and attached to
the VM to emulate the bare metal process. All of this latter process is
currently unimplemented. Thanks,
Alex
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://listman.redhat.com/mailman/listinfo/vfio-users
