Re: [PATCH v4 02/21] iommufd: Add iommufd_sw_map_msi()

[Andrew Jones]

On Wed, Aug 26, 2026 at 01:32:34PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2026 at 10:23:20AM +0200, Andrew Jones wrote:
> > RISC-V uses the same basic model as x86 (an IOMMU-owned interrupt
> > remapping IRQ domain). x86 makes that domain per-IOMMU because its IRTE
> > resources belong to the IOMMU instance. RISC-V makes it per-device because
> > its callbacks operate on the device's attached IOMMU domain and preserve
> > that device's existing MSI parent. The IRQ callbacks provide the lifecycle
> > hooks, even though the mappings, MSI table, and device context all remain
> > IOMMU state.
> 
> The irq domain isn't per device, it is per msi table, many devices can
> share the same table, and the VM should have a single shared table
> across all devices. That's the core uniquely RISCV wrinkle I think.
> 
> IDK how Thomas would like to model this, but you will get a better
> result if it is very clearly explained and asked.
> 
> I would like to keep the iommu out of it, so I prefer if IRQ code
> patches in its MSI table pointer broadly the same way AMD does.
> Though AMD doesn't have the restriction that remapping only works with
> a S2 domain :(
>

The per-device irqdomain model allows multiple devices to share the same
S2 IOMMU domain and MSI table. Unlike AMD, however, the RISC-V remapping
state belongs to a replaceable S2 domain rather than the physical IOMMU.
The IRQ hierarchy must remain stable across domain changes, so a stable
per-device irqdomain which operates on the currently attached S2 domain
may be the closest practical equivalent. I'll explore this further while
reworking the irqbypass series.

Thanks,
drew