On Tue, Apr 18, 2023 at 10:23:55AM +0000, Liu, Yi L wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Monday, April 17, 2023 9:39 PM > > > > On Fri, Apr 14, 2023 at 09:11:30AM +0000, Tian, Kevin wrote: > > > > > The only corner case with this option is when a user mixes group > > > and cdev usages. iirc you mentioned it's a valid usage to be supported. > > > In that case the kernel doesn't have sufficient knowledge to judge > > > 'resettable' as it doesn't know which groups are opened by this user. > > > > IMHO we don't need to support this combination. > > Do you mean we don't support hot-reset for this combination or we don't > support user using this combination. I guess the prior one. Right? Yes > Ditto. We just fail hot-reset for the multiple iommufds case. Is it? Yes > > I suppose we should have done that from the beginning - no-iommu is an > > IOMMUFD access, it just uses a crazy /proc based way to learn the > > PFNs. Making it a proper access and making a real VFIO ioctl that > > calls iommufd_access_pin_pages() and returns the DMA mapped addresses > > to userspace would go a long way to making no-iommu work in a logical, > > usable, way. > > This seems to be an improvement for noiommu mode. It can be done later. > For now, generating access_id and binding noiommu devices with iommufdctx > is enough for supporting noiommu hot-reset. Yes, I'm not sure there is much value in improving no-iommu unless someone also wants to go in and update dpdk. At some point we will need to revise dpdk to use iommufd, maybe that would be a good time to fix this too. The point is that using an access is actually a logical and sensible thing to do, no a hack to make hot reset work better. Jason
