[Intel-gfx] [PATCH v8 21/24] vfio: Add VFIO_DEVICE_BIND_IOMMUFD

Liu, Yi L yi.l.liu at intel.com
Thu Mar 30 12:52:39 UTC 2023


> From: Jason Gunthorpe <jgg at nvidia.com>
> Sent: Thursday, March 30, 2023 7:22 AM
> 
> On Wed, Mar 29, 2023 at 03:00:55PM -0600, Alex Williamson wrote:
> 
> > > + * The user should provide a device cookie when calling this ioctl. The
> > > + * cookie is carried only in event e.g. I/O fault reported to userspace
> > > + * via iommufd. The user should use devid returned by this ioctl to mark
> > > + * the target device in other ioctls (e.g. iommu hardware infomration query
> > > + * via iommufd, and etc.).
> >
> > AFAICT, the whole concept of this dev_cookie is a fantasy.  It only
> > exists in this series in these comments and the structure below.  It's
> > not even defined whether it needs to be unique within an iommufd
> > context, and clearly nothing here validates that.  There's not enough
> > implementation for it to exist in this series.  Maybe dev_cookie is
> > appended to the end of the structure and indicated with a flag when it
> > has some meaning.
> 
> Yes, I've asked for this to be punted to the PRI series enough times
> already, why does it keep coming back ??

yes, I promise to remove it in next version.

> > > + * @argsz:	 user filled size of this data.
> > > + * @flags:	 reserved for future extension.
> > > + * @dev_cookie:	 a per device cookie provided by userspace.
> > > + * @iommufd:	 iommufd to bind. a negative value means noiommu.
> >
> > "Use a negative value for no-iommu, where supported", or better, should
> > we define this explicitly as -1, or why not use a flag bit to specify
> > no-iommu?  Maybe minsz is only through flags for the noiommu use case.
> 
> I was happy enough for this to be defined as -1. We could give it a
> formal sounding constant too

are you suggesting having something like "#define VFIO_NOIOMMU_FD	-1"?

Regards,
Yi Liu


More information about the Intel-gfx mailing list