On Mon, Jan 09, 2023 at 11:07:06PM +0800, Yi Liu wrote: > On 2023/1/9 22:14, Jason Gunthorpe wrote: > > On Mon, Jan 09, 2023 at 07:47:03AM +0000, Tian, Kevin wrote: > > > > From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > > > > Sent: Monday, December 19, 2022 4:47 PM > > > > > > > > @@ -415,7 +416,7 @@ static int vfio_device_first_open(struct > > > > vfio_device_file *df, > > > > if (!try_module_get(device->dev->driver->owner)) > > > > return -ENODEV; > > > > > > > > - if (iommufd) > > > > + if (iommufd && !IS_ERR(iommufd)) > > > > ret = vfio_iommufd_bind(device, iommufd, dev_id, pt_id); > > > > else > > > > ret = vfio_device_group_use_iommu(device); > > > > > > can you elaborate how noiommu actually works in the cdev path? > > > > I still need someone to test the noiommu iommufd patch with dpdk, I'll > > post it in a minute > > I remembered I had mentioned I found one guy to help. But he mentioned > to me he has got some trouble. I think it may be due to environment. Let > me check with him tomorrow about if any update. > > > For cdev conversion no-iommu should be triggered by passing in -1 for > > the iommufd file descriptor to indicate there is no translation. Then > > the module parameter and security checks should be done before > > allowing the open to succeed with an identity translation in place. > > > > There should be a check that there is no iommu driver controlling the > > device as well.. > > yes. I used ERR_PTR(-EINVAL) as an indicator of noiommu in this patch. > I admit this logic is incorrect. Should be Oh please don't store ERR_PTRs in a structs.. Jason
