[Intel-gfx] [PATCH v1 1/5] iommufd: Create access in vfio_iommufd_emulated_bind()

[Tian, Kevin]

> From: Nicolin Chen <nicolinc at nvidia.com>
> Sent: Wednesday, March 15, 2023 9:01 AM
> 
> Hi Jason/Kevin,
> 
> >
> > Perhaps we can have iommufd_access_attach/detach in this series
> > along with a vfio_iommufd_emulated_detach_ioas, and the locking
> > will come with another patch in replace series?
> 
> I recall that we previously concluded that the unbind() is safe
> to go without doing access->ops->unmap, because close_device()
> would be called prior to the unbind().
> 
> But, to add the vfio_iommufd_emulated_detach_ioas() in the cdev
> series, we'd need the access->ops->unmap call, and the locking
> and "ioas_unpin" too in the detach and attach APIs, right?

yes. We need locking since detach can happen any time with 
cdev while driver is conducting pinning.

> 
> I tried a bit of some update, across this series, cdev series,
> and the replace series. Though we might be able to simplify a
> bit of this patch/series, yet it doesn't seem to simplify the
> changes overall, particularly in the following cdev series for
> having an unmap() call and the locking.
> 
> Then the replace API would mostly overlap with the attach API,
> by only having an additional detach(), which means actually we
> only need an iommufd_access_attach API to cover both cases...

there is a subtle difference. to match the physical path:

for attach we expect the existing access->ioas is either NULL or
same as the new ioas.

for replace access->ioas must exist.

they need different condition checks.