> From: Nicolin Chen <nicolinc@xxxxxxxxxx> > 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.
