On 2025-02-21 4:44 pm, Jason Gunthorpe wrote:
On Fri, Feb 21, 2025 at 03:39:45PM +0000, Robin Murphy wrote:
Yuck. Realistically we are going to have no more than two different
implementations of this; a fiddly callback interface seems overkill. All we
should need in the domain is a simple indicator of *which* MSI translation
scheme is in use (if it can't be squeezed into the domain type itself), then
iommu_dma_prepare_msi() can simply dispatch between iommu-dma and IOMMUFD
based on that, and then it's easy to solve all the other fragility issues
too.
That would make module dependency problems, we have so far avoided
having the core kernel hard depend on iommufd.
It wouldn't need a hard dependency, it's easy to have a trivial built-in
stub function which becomes valid once the module loads - you literally
have the iommufd_driver infrastructure for precisely that sort of thing
already. All I'm saying is to hide the callback detail in the IOMMUFD
code because being IOMMUFD modular is unique to IOMMUFD and not the rest
of the core code's problem.
And frankly otherwise, what even is the benefit of moving the
iova_cookie pointer into the union if we have to replace it with another
whole pointer to make it work? This is just adding more code and more
complexity in in order to make struct iommu_domain... the same size it
already is :/
Thanks,
Robin.
