[Intel-gfx] [PATCH v8 00/24] Add vfio_device cdev for iommufd support

Jiang, Yanting yanting.jiang at intel.com
Fri Mar 31 03:10:48 UTC 2023


> On 2023/3/27 02:40, Yi Liu wrote:
> Existing VFIO provides group-centric user APIs for userspace. Userspace opens
> the /dev/vfio/$group_id first before getting device fd and hence getting access
> to device. This is not the desired model for iommufd. Per the conclusion of
> community discussion[1], iommufd provides device-centric kAPIs and requires its
> consumer (like VFIO) to be device-centric user APIs. Such user APIs are used to
> associate device with iommufd and also the I/O address spaces managed by the
> iommufd.
> 
> This series first introduces a per device file structure to be prepared for further
> enhancement and refactors the kvm-vfio code to be prepared for accepting
> device file from userspace. Afte this, adds a mechanism for blocking device
> access before iommufd bind. Then refactors the vfio to be able to handle cdev
> path (e.g. iommufd binding, no-iommufd, [de]attach ioas).
> This refactor includes making the device_open exclusive between group and
> cdev path, only allow single device open in cdev path; vfio-iommufd code is also
> refactored to support cdev. e.g. split the vfio_iommufd_bind() into two steps.
> Eventually, adds the cdev support for vfio device and the new ioctls, then makes
> group infrastructure optional as it is not needed when vfio device cdev is
> compiled.
> 
> This series is based on some preparation works done to vfio emulated devices[2]
> and vfio pci hot reset enhancements[3].
> 
> This series is a prerequisite for iommu nesting for vfio device[4] [5].
> 
> The complete code can be found in below branch, simple tests done to the
> legacy group path and the cdev path. Draft QEMU branch can be found at[6]
> 
> https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v8
> (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y)
> 

Tested NIC passthrough on Intel platform with above branch (commit id: 9464af85d280511639f8a3e27b6c2a2c5535fa4c).
Result looks good hence, 
Tested by: Jiang, Yanting <yanting.jiang at intel.com>

Thanks,
Yanting



More information about the Intel-gfx mailing list