Message ID | 20230327094047.47215-1-yi.l.liu@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | Add vfio_device cdev for iommufd support | expand |
On Mon, Mar 27, 2023 at 02:40:23AM -0700, Yi Liu wrote: > External email: Use caution opening links or attachments > > > 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) > > base-commit: 1d412cdf6cd17c347b5398416a60518671e13d37 > > [1] https://lore.kernel.org/kvm/BN9PR11MB5433B1E4AE5B0480369F97178C189@BN9PR11MB5433.namprd11.prod.outlook.com/ > [2] https://lore.kernel.org/kvm/20230327093351.44505-1-yi.l.liu@intel.com/ > [3] https://lore.kernel.org/kvm/20230327093458.44939-1-yi.l.liu@intel.com/ > [4] https://lore.kernel.org/linux-iommu/20230309080910.607396-1-yi.l.liu@intel.com/ > [5] https://lore.kernel.org/linux-iommu/20230309082207.612346-1-yi.l.liu@intel.com/ > [6] https://github.com/yiliu1765/qemu/tree/iommufd_rfcv3 (it is based on Eric's > QEMU iommufd rfcv3 (https://lore.kernel.org/kvm/20230131205305.2726330-1-eric.auger@redhat.com/) > plus commits to align with vfio_device_cdev v8) > > Change log: > > v8: > - Add patch 18 to determine noiommu device at vfio_device registration (Jason) > - Add patch 19 to name noiommu device with "noiommu-" prefix to be par with > group path > - Add r-b from Kevin > - Add t-b from Terrence This runs well with iommufd selftest on x86 and QEMU sanity on ARM64, applying nesting series on top of this series: https://github.com/nicolinc/iommufd/commits/wip/iommufd_nesting-03272023 Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> 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@intel.com> Thanks, Yanting
> 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-by: Yanting Jiang <yanting.jiang@intel.com> Thanks, Yanting