> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > 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
