> From: Tian, Kevin > Sent: Friday, February 3, 2023 5:24 PM > > > 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? Obviously this doesn't work with what 'replace' requires in following patches. So please just ignore this comment...
