> From: Jason Gunthorpe <j...@nvidia.com> > Sent: Wednesday, June 8, 2022 7:27 PM > > On Wed, Jun 08, 2022 at 03:47:12AM +0000, Tian, Kevin wrote: > > > From: Jason Gunthorpe > > > Sent: Wednesday, June 8, 2022 7:02 AM > > > > > > Instead of bouncing the function call to the driver op through a blocking > > > notifier just have the iommu layer call it directly. > > > > > > Register each device that is being attached to the iommu with the lower > > > driver which then threads them on a linked list and calls the appropriate > > > driver op at the right time. > > > > > > Currently the only use is if dma_unmap() is defined. > > > > > > Also, fully lock all the debugging tests on the pinning path that a > > > dma_unmap is registered. > > > > > ... > > > Signed-off-by: Jason Gunthorpe <j...@nvidia.com> > > > diff --git a/drivers/vfio/vfio_iommu_type1.c > > > b/drivers/vfio/vfio_iommu_type1.c > > > index c13b9290e35759..4ddb1f1abd238b 100644 > > > +++ b/drivers/vfio/vfio_iommu_type1.c > > > @@ -67,7 +67,8 @@ struct vfio_iommu { > > > struct list_head iova_list; > > > struct mutex lock; > > > struct rb_root dma_list; > > > - struct blocking_notifier_head notifier; > > > + struct list_head device_list; > > > + struct mutex device_list_lock; > > > > emulated_device_list or unmap_device_list, to be more accurate? > > I don't think it is worth getting too specific here, the fact it only > has dma_unmap devices is a bit of a shortcut to save some work. > > > btw a few lines downward there is already a emulated_iommu_groups. > > the two sounds a bit overlapping given mdev's iommu group is faked > > and singleton. Wonder whether it's cleaner to just reuse the existing > > field... > > The locking is more complicated on this since we still have check > every device in the group if it is opened or not while launching the > callback and prevent it from opening/closing while the callback is > running. > > Since I plan to delete the dirty tracking which will drop the > emulated_iommu_groups too I would leave it like this. >
Make sense. Reviewed-by: Kevin Tian <kevin.t...@intel.com>