From: Jason Gunthorpe jgg@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 jgg@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.tian@intel.com