On Fri, Feb 07 2025 at 10:34, Jason Gunthorpe wrote:
On Fri, Jan 10, 2025 at 07:32:16PM -0800, Nicolin Chen wrote:
Though these two approaches feel very different on the surface, they can share some underlying common infrastructure. Currently, only one pair of sw_msi functions (prepare/compose) are provided by dma-iommu for irqchip drivers to directly use. There could be different versions of functions from different domain owners: for existing VFIO passthrough cases and in- kernel DMA domain cases, reuse the existing dma-iommu's version of sw_msi functions; for nested translation use cases, there can be another version of sw_msi functions to handle mapping and msi_msg(s) differently.
To support both approaches, in this series
- Get rid of the duplication in the "compose" function
- Introduce a function pointer for the previously "prepare" function
- Allow different domain owners to set their own "sw_msi" implementations
- Implement an iommufd_sw_msi function to additionally support a nested translation use case using the approach (2), i.e. the RMR solution
- Add a pair of IOMMUFD options for a SW_MSI window for kernel and VMM to agree on (for approach 1)
- Add a new VFIO ioctl to set the MSI(x) vector(s) for iommufd_sw_msi() to update the msi_desc structure accordingly (for approach 2)
Thomas/Marc/Robin, are we comfortable with this general approach? Nicolin can send something non-RFC for a proper review.
I like it, it solves many of the problems iommufd had here and it seems logical from the irq side.
I haven't seen anything horrible. My main concern of having a proper cached and writeable message is addressed.
Thanks,
tglx