> 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@xxxxxxxxx> Thanks, Yanting
