> From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > Sent: Sunday, March 5, 2023 10:49 PM > > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > Sent: Saturday, March 4, 2023 12:56 AM > > > > On Fri, 3 Mar 2023 06:36:35 +0000 > > "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > > > > use of noiommu should be discouraged. > > > > > > if only known noiommu user doesn't use it then having certain > > > new restriction for noiommu in the hot reset path might be an > > > acceptable tradeoff. > > > > > > but again needs Alex's input as he knows all the history about > > > noiommu. 😊 > > > > No-IOMMU mode was meant to be a minimally invasive code change to > > re-use the vfio device interface, or alternatively avoid extending > > uio-pci-generic to support MSI/X, with better logging/tainting to know > > when userspace is driving devices without IOMMU protection, and as a > > means to promote a transition to standard support of vfio. AFAIK, > > there are still environments without v/IOMMU that make use of no-iommu > > mode. Thanks, > > This makes Jason's remark (noiommu should not use iommufd at all) much > more reasonable. If there is no v/IOMMU, then no iommufd at all. yeah, viommu is a good point. > > If no iommufd is used in the no-iommu mode, this approach cannot > tell two applications that are operating in no-iommu mode. If we allow > reset, it may make no-iommu mode more weak. So perhaps we need > to have another approach for this ownership check. > > 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.
