RE: [PATCH v5 16/19] vfio: Add VFIO_DEVICE_BIND_IOMMUFD

Tian, Kevin
2023-03-08T07:17:31Z

> From: Liu, Yi L <yi.l.liu@intel.com>
> Sent: Tuesday, March 7, 2023 9:04 PM
>
> > From: Jason Gunthorpe <jgg@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@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/
>

Probably not necessary. It's user to get info and then create hwpt.
I don't think we'll ever add a check whether the user has acquired
the info before creating the hwpt. From this angle there is no
dependency in code-wise.

My earlier comment was based on the user creating hwpt w/o
querying the info. Looks it's just user's job to make it right. We
may clarify this point in hwpt_alloc uAPI comment.