> From: Nicolin Chen <nicolinc@xxxxxxxxxx> > Sent: Thursday, February 2, 2023 3:05 PM > > To prepare for an access->ioas replacement, move iommufd_access_create() > call into vfio_iommufd_emulated_bind(), making it symmetric with the > __vfio_iommufd_access_destroy() call in vfio_iommufd_emulated_unbind(). > This means an access is created/destroyed by the bind()/unbind(), and the > vfio_iommufd_emulated_attach_ioas() only updates the access->ioas pointer. > > Since there's no longer an ioas_id input for iommufd_access_create(), add > a new helper iommufd_access_set_ioas() to set access->ioas. We can later > add a "replace" feature simply to the new iommufd_access_set_ioas() too. > > Leaving the access->ioas in vfio_iommufd_emulated_attach_ioas(), however, > can introduce some potential of a race condition during pin_/unpin_pages() > call where access->ioas->iopt is getting referenced. So, add an ioas_lock > to protect it. > What about introducing another flag e.g. vdev->iommufd_access_attached which got set in vfio_iommufd_emulated_attach_ioas() to fulfill what vdev->iommufd_access guards today?
