On Tue, Feb 28, 2023 at 12:56:11PM +0000, Liu, Yi L wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Tuesday, February 28, 2023 8:52 PM > > > > On Tue, Feb 28, 2023 at 12:45:47PM +0000, Liu, Yi L wrote: > > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > > Sent: Tuesday, February 28, 2023 8:31 PM > > > > > > > > On Tue, Feb 28, 2023 at 06:58:38AM +0000, Liu, Yi L wrote: > > > > > > > > > Seems like pt_id is no more needed in the vfio_iommufd_bind() > > > > > since it can get compat_ioas_id in the function itself. Cdev path > > > > > never passes a pt_id to vfio_iommufd_bind() as its attach is done > > > > > by separate ATTACH ioctl. Can we use the dev_id pointer to indicate > > > > > if it needs to get the compat ioas and attach it? > > > > > > > > In this case you need to split the group code to also use the two step > > > > attach and then the attach will take in the null pt_id. > > > > > > This seems to be the current way in this patch. Right? Group code passes > > > a pt_id pointer to vfio_iommufd_bind(). While the cdev path just passes > > > in a null pt_id pointer. Its attach is done later when user gives pt_id. > > > > I mean actually explicitly call attach and remove the implicit attach > > during bind flow entirely. > > Okay, so I can wrap the iommufd_vfio_compat_ioas_id() and ops->attach_ioas > in a helper for group code to do attach after bind_iommufd. This can avoid to > moving the iommufd_vfio_compat_ioas_id() out of iommufd.c as your original > remark. > > Is this ok? Yes, some 'attach compat' helper makes sense Jason
