> From: Tian, Kevin <kevin.tian@xxxxxxxxx>
> Sent: Monday, March 6, 2023 4:23 PM
> > From: Tian, Kevin <kevin.tian@xxxxxxxxx>
> > Sent: Monday, March 6, 2023 4:17 PM
> >
> > > From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
> > > Sent: Sunday, March 5, 2023 10:49 PM
> > >
> > >
> > > How about falling back to prior solution. Allow userspace to pass a set
> > > of device fd, and the kernel just checks the opened devices in the
> dev_set,
> > > all the opened devices should be included in the device fd set. If not all
> > > of them are included, fail it.
> > >
> >
> > looks this is a cleaner approach.
> >
> > if a device is not opened we know it's safe to reset.
> >
> > If a device is opened then it must be opened by the calling process to be
> > reset.
> >
> > from this angle we don't need to bother with noiommu vs. iommufd
> > when iommufd is not always available.
>
> btw there is one thing to be fixed in your next version.
>
> noiommu shouldn't be enabled on a device which always has a iommu
> group.
>
> We need a check on iommu_group in following place:
>
> + /* iommufd < 0 means noiommu mode */
> + if (bind.iommufd < 0) {
> + if (!capable(CAP_SYS_RAWIO)) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> + df->noiommu = true;
Yes. it is. If there is iommu in the system, noiommu mode is not available.
Checking iommu_group presence could detect it. 😊
Regards,
Yi Liu
