RE: [PATCH v10 00/22] Add vfio_device cdev for iommufd support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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


 




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux