> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, August 24, 2022 8:38 AM > > On Tue, Aug 23, 2022 at 01:31:11AM +0000, Tian, Kevin wrote: > > > > In fact I do recall such discussions. An IOMMU backed mdev (defunct) > > > or vfio-pci variant driver could gratuitously pin pages in order to > > > limit the dirty page scope. We don't have anything in-tree that relies > > > on this. It also seems we're heading more in the direction of device > > > level DMA dirty tracking as Yishai proposes in the series for mlx5. > > > These interfaces are far more efficient for this use case, but perhaps > > > you have another use case in mind where we couldn't use the dma_rw > > > interface? > > > > One potential scenario is when I/O page fault is supported VFIO can > > enable on-demand paging in stage-2 mappings. In case a device cannot > > tolerate faults in all paths then a variant driver could use this interface > > to pin down structures which don't expect faults. > > If this need arises, and I've had discussions about such things in the > past, it makes more sense to have a proper API to inhibit faulting of > a sub-range in what would have otherwise be a faultable iommu_domain. > > Inhibiting faulting might be the same underlying code as pinning, but > I would prefer we don't co-mingle these very different concepts at the > device driver level. > > > IMHO if functionally this function only works for emulated case then we > > should add code to detect and fail if it's called otherwise. > > Today it only works correctly for the emulated case because only the > emulated case will be guarenteed to have a singleton group. > > It *might* work for other cases, but not generally. In the general > case a physical device driver may be faced with multi-device groups > and it shouldn't fail. > > So, I would prefer to comment it like this and if someone comes with a > driver that wants to use it in some other way they have to address > these problems so it works generally and correctly. I don't want to > write more code to protect against something that auditing tells us > doesn't happen today. > With all the discussions in this thread I'm fine adding a comment like this (though not my preference which is not strong either): Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
