RE: [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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?

Regards,
Yi Liu




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux