Re: [PATCH v2 3/7] iommu: Make iommu_dma_prepare_msi() into a generic operation

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Feb 27, 2025 at 11:21:28AM +0000, Robin Murphy wrote:

> 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.

Yes, but I also kinda dislike using it because it bloats the built in
kernel for a narrow use case..

> 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.

Maybe we could use a global function pointer set/cleared on iommufd
module load?

Regardless, we need to first find a way for the core code to tell if
the domain is iommufd owned or not.

We should also make it so we can tell if dma-iommu.c is linked to that
domain (eg vfio or the default_domain), then we can do the iova_cookie
move without changing the destruction flows. This would be the missing
union struct tag you mentioned in the other email.

What I've been thinking of is changing type into flags. I think we
have now removed type from all drivers so this should be a small
enough work.

Nicolin should be able to look into some followup here, it is not a
small change.

> 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?

It makes a lot more semantic sense that the domain owners all share a
single "private data" pointer.

> This is just adding more code and more complexity in in
> order to make struct iommu_domain... the same size it already is :/

That we get back the space we spent on sw_msi is a nice bonus.

Jason