[Intel-gfx] [PATCH v10 00/22] Add vfio_device cdev for iommufd support

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Jiang, Yanting [mailto:yanting.jiang at intel.com]
> Sent: 28 April 2023 10:30
> To: Liu, Yi L <yi.l.liu at intel.com>; alex.williamson at redhat.com;
> jgg at nvidia.com; Tian, Kevin <kevin.tian at intel.com>
> Cc: joro at 8bytes.org; robin.murphy at arm.com; cohuck at redhat.com;
> eric.auger at redhat.com; nicolinc at nvidia.com; kvm at vger.kernel.org;
> mjrosato at linux.ibm.com; chao.p.peng at linux.intel.com;
> yi.y.sun at linux.intel.com; peterx at redhat.com; jasowang at redhat.com;
> Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>;
> lulu at redhat.com; suravee.suthikulpanit at amd.com;
> intel-gvt-dev at lists.freedesktop.org; intel-gfx at lists.freedesktop.org;
> linux-s390 at vger.kernel.org; Hao, Xudong <xudong.hao at intel.com>; Zhao,
> Yan Y <yan.y.zhao at intel.com>; Xu, Terrence <terrence.xu at intel.com>; Duan,
> Zhenzhong <zhenzhong.duan at 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 at 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 at huawei.com>

Thanks,
Shameer