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

[Nicolin Chen <nicolinc@nvidia.com>]

On Wed, Mar 15, 2023 at 06:15:23AM +0000, Tian, Kevin wrote:
> External email: Use caution opening links or attachments
> 
> 
> > From: Nicolin Chen <nicolinc@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.

So, this preparatory series will add a pair of simple attach()
and detach() APIs. Then the cdev series will add the locking
and the ioas_unpin stuff as a rework of the detach() API.

> > 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.

I think they can be something mingled... the sample code that
I sent previously could take care of those conditions. But, I
am also thinking a bit that maybe attach() does not need the
locking? I can do a separate replace() function in this case.

Thanks
Nic