> From: Tian, Kevin <kevin.t...@intel.com>
> Sent: Monday, March 6, 2023 4:23 PM
> > From: Tian, Kevin <kevin.t...@intel.com>
> > Sent: Monday, March 6, 2023 4:17 PM
> >
> > > From: Liu, Yi L <yi.l....@intel.com>
> > > 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

Reply via email to