On Tue, Oct 28, 2025 at 10:39:45AM -0700, Jacob Pan wrote:
My current approach is that I have a special noiommu driver that handles the special iommu_domain. It seems much cleaner though some extra code overhead. I have a working prototype that has:
Oh interesting, maybe that is OK and reasonable.. My first worry is that we don't well support iommu driver hot unplug, but if it is very carefully controlled I think we can make it safe. iommufd selftests is already doing this and I've been trying to make sure it stays safe without races or memory leaks..
Binding is going to also need some fiddling because we don't want to mess with the fwspec on a real struct device..
But maybe we can have some kind of direct 'bind iommu driver to struct device' call?
The following user test can pass:
- __iommufd = open("/dev/iommu", O_RDWR);
- devfd = open a noiommu cdev
- ioas_id = ioas_alloc(__iommufd)
- iommufd_bind(__iommufd, devfd)
- successfully do an ioas map, e.g.
ioctl(iommufd, IOMMU_IOAS_MAP, &map) This will call pfn_reader_user_pin() but the noiommu driver does nothing for mapping.
Make sense.
So you can't have a paging iommu_domain that doesn't have a map function - that just won't work for iommufd. What you should do is use the iommu pt stuff and have the noiommu driver implement its paging domain using the amdv1 format.
That will give you map/unmap/iova_to_phys and then iommufd will immediately full work.
Look at how that series handles the selftest, the simple selftest iommu_domain is very close to what you need. It is pretty small code wise.
After writing the generic pt self test it occured to me we now have enough infrastructure for iommufd to internally create its own iommu_domain with a AMDv1 page table for the noiommu devices. It would then be so easy to feed that through the existing machinery and have all the pinning/etc work.
Could you elaborate a little more? noiommu devices don't have page tables. Are you saying iommufd can create its own iommu_domain w/o a vendor iommu driver? Let me catch up with your v7 :)
That was my suggestion, but it seems you tried that and decided it was too hard with groups/etc. OK.
Adding a dummy iommu driver solves that and you still get to the same place where there is a paging iommu domain that implements an actual page table with map/unmap/iova_to_phys. From this perspective iommufd will be entirely happy and will do all the required pinning and unpinning.
Then only an ioctl to read back the physical addresses from this special domain would be needed
Yes, that was part of your original suggestion to avoid /proc pagemap. I have not added that yet. Do you think this warrant a new ioctl or just return it in
I think a new ioctl is probably the right idea..
Jason