On Mon, Mar 20, 2023 at 11:11:51PM +0800, Yi Liu wrote: > > > On 2023/3/20 22:49, Jason Gunthorpe wrote: > > On Wed, Mar 15, 2023 at 02:03:09AM -0700, Nicolin Chen wrote: > > > Hi, > > > > > > On Wed, Mar 15, 2023 at 06:50:53AM +0000, Tian, Kevin wrote: > > > > > > > > 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 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. > > > > > > > > > > > > > w/o locking then you need smp_store_release() and its pair. > > > > > > > > anyway it's not in perf critical path. Keeping lock for attach > > > > is simpler and safe. > > > > > > OK. Basically I followed what Jason suggested by having three > > > APIs and combined Kevin's inputs about the difference between > > > the attach/replace(). I also updated the replace changes, and > > > rebased all nesting (infrastructure, VT-d and SMMU): > > > https://github.com/nicolinc/iommufd/commits/wip/iommufd_nesting-03142023 > > > > > > The major three changes for those APIs: > > > [1] This adds iommufd_access_attach() in this series: > > > "iommufd: Create access in vfio_iommufd_emulated_bind()" > > > https://github.com/nicolinc/iommufd/commit/34fba7509429380f828fb23dcca5ceaeb40e22b5 > > > [2] This adds iommufd_access_detach() in the cdev series: > > > "iommufd/device: Add iommufd_access_detach() API" > > > https://github.com/nicolinc/iommufd/commit/4110522146ca1fc0d5321c04a097e2c9d9e26af4 > > > [3] This adds iommufd_access_replace() in the replace series: > > > "iommufd: Add iommufd_access_replace() API" > > > https://github.com/nicolinc/iommufd/commit/36507fa9f0f42cf1a5bebe7c9bc2bf319b7654a8 > > > > > > Please check if they look okay, so that Yi can integrate them > > > accordingly to the emulated/cdev series. > > > > I don't understand why this is being put in front of the cdev series? > > because we want to make emulated devices have iommufd_access in the > bind, then it can return iommufd_access->obj.id to userspace when > adding cdev. Ah OK Jason
