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
