Re: [PATCH v2] vfio: Remove vfio_group dev_counter

[Jason Gunthorpe <jgg@nvidia.com>]

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.

The whole thing should naturally become fixed fairly soon, as once we
have Yishai and Joao's changes there will be no use for the dirty
tracking code in type1 that is causing this problem.

Jason