[Intel-gfx] [PATCH v5 16/19] vfio: Add VFIO_DEVICE_BIND_IOMMUFD

[Liu, Yi L]

> From: Jason Gunthorpe <jgg at nvidia.com>
> Sent: Tuesday, March 7, 2023 8:38 PM
> 
> On Tue, Mar 07, 2023 at 06:38:59AM +0000, Tian, Kevin wrote:
> > > From: Liu, Yi L <yi.l.liu at intel.com>
> > > Sent: Friday, March 3, 2023 2:58 PM
> > >
> > > > What should we return here anyhow if an access was created?
> > >
> > > iommufd_access->obj.id. should be fine. Is it?
> >
> > Thinking more I'm not sure whether it's a good idea to fill the
> > dev_id field with an access object id and then later confuse
> > the user to get an -ENOENT error when trying to allocate a
> > hwpt with an access object id.
> >
> > How can user differentiate it from the real error case where
> > invalid iommufd object is used?
> >
> > It sounds clearer to return dev_id only when there is a true
> > device object being created by the bind_iommufd cmd. Then
> > the user can use it to decide whether  to further attempt
> > dev_id related cmds.
> 
> It means we can never return an access_id
> 
> I don't think this is a problem, the first thing userspace should do
> is a get info to the dev_id which is needed to learn which iommu
> driver is running it, if that returns EOPNOTSUPP then it isn't a
> physical iommu device.

This may mean your below patch depends on the get info series. 😊
Also need to update the description to the ioctl.

https://lore.kernel.org/linux-iommu/12-v1-7612f88c19f5+2f21-iommufd_alloc_jgg@nvidia.com/

Regards,
Yi Liu