> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, November 23, 2022 1:41 AM > > > BTW, what is the actual expected use case of passing an iommufd as a > > vfio container? I have doubts that it'd make sense to have QEMU look > > for an iommufd in place of a vfio container for anything beyond yet > > another means for early testing of iommufd. Thanks, One case is that the admin links /dev/vfio/vfio to /dev/iommu then all legacy vfio applications are implicitly converted to use iommufd as vfio container. > > I don't think there is one in production for qemu. > > For something like DPDK I can imagine replacing the open logic to use > vfio device cdevs and iommufd, but keeping the rest of the logic the > same so the FD looks and feels like a VFIO container. There is little > value in replacing the VFIO map/unmap/etc ioctls with the IOMMUFD > equivalents. > I'm not sure the value of entering this mixed world. I could envision dpdk starting to add cdev/iommufd support when it wants to use new features (pasid, iopf, etc.) which are available only via iommufd native api. Before that point it just stays with full vfio legacy.
