[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