Message ID | 20230426150321.454465-1-yi.l.liu@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | Add vfio_device cdev for iommufd support | expand |
> Subject: [PATCH v10 00/22] Add vfio_device cdev for iommufd support > > 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. After 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 the group and > the 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] > However, the noiommu mode test is only done with some hacks in kernel and > qemu to check if qemu can boot with noiommu devices. > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v10 > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > base-commit: c3822365940319ad86487cc1daf6f1a4c271191e > (based on Alex's next branch and merged the vfio_mdev_ops branch from > Jason's repo) > Tested NIC passthrough on Intel platform. Result looks good hence, Tested-by: Yanting Jiang <yanting.jiang@intel.com> Thanks, Yanting
> -----Original Message----- > From: Jiang, Yanting [mailto:yanting.jiang@intel.com] > Sent: 28 April 2023 10:30 > To: Liu, Yi L <yi.l.liu@intel.com>; alex.williamson@redhat.com; > jgg@nvidia.com; Tian, Kevin <kevin.tian@intel.com> > Cc: joro@8bytes.org; robin.murphy@arm.com; cohuck@redhat.com; > eric.auger@redhat.com; nicolinc@nvidia.com; kvm@vger.kernel.org; > mjrosato@linux.ibm.com; chao.p.peng@linux.intel.com; > yi.y.sun@linux.intel.com; peterx@redhat.com; jasowang@redhat.com; > Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>; > lulu@redhat.com; suravee.suthikulpanit@amd.com; > intel-gvt-dev@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; > linux-s390@vger.kernel.org; Hao, Xudong <xudong.hao@intel.com>; Zhao, > Yan Y <yan.y.zhao@intel.com>; Xu, Terrence <terrence.xu@intel.com>; Duan, > Zhenzhong <zhenzhong.duan@intel.com> > Subject: RE: [PATCH v10 00/22] Add vfio_device cdev for iommufd support > > > Subject: [PATCH v10 00/22] Add vfio_device cdev for iommufd support > > > > 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. After 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 the > group and > > the 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] > > However, the noiommu mode test is only done with some hacks in kernel > and > > qemu to check if qemu can boot with noiommu devices. > > > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v10 > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > base-commit: c3822365940319ad86487cc1daf6f1a4c271191e > > (based on Alex's next branch and merged the vfio_mdev_ops branch from > > Jason's repo) > > > > Tested NIC passthrough on Intel platform. > Result looks good hence, > Tested-by: Yanting Jiang <yanting.jiang@intel.com> Likewise, tested on HiSilicon D06(ARM64) platform with a NIC pass-through device and looks fine. FWIW, Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Thanks, Shameer