> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Tuesday, April 18, 2023 9:02 PM > > 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. This noiommu improvement shall allow user to attach ioas to noiommu devices. is it? This may be done by calling iommufd_access_attach(). So there is a quick question. In the cdev series, shall we allow the attachment for noiommu? I think the noiommu improvement shall require extra effort, so it is not ready yet. If so, seems like I just need to fail the attachment for noiommu devices. But when in the future it is ready, how can userspace know attach is allowed for noiommu devices? Will it be an easy thing? or we may just let the attach as a noop and always succeed for noiommu devices? any suggestions? Regards, Yi Liu
