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