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. Thanks, Jason
