> -----Original Message----- > From: Jiang, Yanting [mailto:yanting.jiang@xxxxxxxxx] > Sent: 28 April 2023 10:30 > To: Liu, Yi L <yi.l.liu@xxxxxxxxx>; alex.williamson@xxxxxxxxxx; > jgg@xxxxxxxxxx; Tian, Kevin <kevin.tian@xxxxxxxxx> > Cc: joro@xxxxxxxxxx; robin.murphy@xxxxxxx; cohuck@xxxxxxxxxx; > eric.auger@xxxxxxxxxx; nicolinc@xxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; > mjrosato@xxxxxxxxxxxxx; chao.p.peng@xxxxxxxxxxxxxxx; > yi.y.sun@xxxxxxxxxxxxxxx; peterx@xxxxxxxxxx; jasowang@xxxxxxxxxx; > Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx>; > lulu@xxxxxxxxxx; suravee.suthikulpanit@xxxxxxx; > intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; > linux-s390@xxxxxxxxxxxxxxx; Hao, Xudong <xudong.hao@xxxxxxxxx>; Zhao, > Yan Y <yan.y.zhao@xxxxxxxxx>; Xu, Terrence <terrence.xu@xxxxxxxxx>; Duan, > Zhenzhong <zhenzhong.duan@xxxxxxxxx> > 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@xxxxxxxxx> Likewise, tested on HiSilicon D06(ARM64) platform with a NIC pass-through device and looks fine. FWIW, Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@xxxxxxxxxx> Thanks, Shameer
