Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH v1 3/8] iommufd: Create access in vfio_iommufd_emulated_bind() | Date | Fri, 3 Feb 2023 09:28:03 +0000 |
| |
> From: Tian, Kevin > Sent: Friday, February 3, 2023 5:24 PM > > > From: Nicolin Chen <nicolinc@nvidia.com> > > 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...
| |