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

On Sat, Aug 22, 2026 at 11:06:25AM -0300, Jason Gunthorpe wrote:
> On Sat, Aug 22, 2026 at 03:50:05PM +0200, Andrew Jones wrote:
> > With the RISC-V IOMMU MSI table and irqbypass support in KVM, we can
> > write the guest's MSI messages directly to the device without
> > interpreting the IOVAs. 
> 
> Every architecture can work this way. Nobody has impleented Linux
> support for it, and if we do, it must be arch generic.
> 
> Not being able to discover the vCPU from the MSI descriptor means you
> can't use any of the existing less-optimal Linux flows and are forced
> to implement this hard thing..

The RISC-V irqbypass work does not require a new framework, or even
callback. It uses the existing irqbypass framework and implements
irq_set_vcpu_affinity(). Since that callback programs the IOMMU MSI table,
it belongs in the IOMMU irqdomain.

> 
> > Guest changes to S1 or IRQ affinity therefore do not require MSI table
> > updates. And, when a vCPU moves to another pCPU, or switches between a
> > VS-file and an MRIF, the hypervisor only updates the MSI table entry for
> > that vIMSIC GPA. The device message and S1 mapping are unaffected.
> 
> I'm not sure how you will end up controlling the msi table..

Through irq_set_vcpu_affinity()

> 
> > As I understand it, Nicolin's series addresses the ARM split between
> > SMMU translation and ITS interrupt remapping. 
> 
> ARM is basically the same, the ITS page goes through the S1 and S2, so
> the goal is to get a valid ITS page into the S2, tell the guest to use
> it and create a S1 pointing at it then feed the MSI descriptor from
> the guest unmodified to the HW.

On ARM, the SMMU translates the MSI address, but the ITS performs the
interrupt remapping. KVM must therefore know which vITS the guest IOVA
selects so it can resolve that vITS's DeviceID/EventID mapping and program
the physical ITS with the corresponding vCPU-specific state.

RISC-V has no equivalent ITS state. An IMSIC at msi.addr simply receives
msi.data. If every vIMSIC GPA is mapped in the MSI table, the guest IOVA
can remain opaque. S1 selects the vIMSIC GPA and that GPA selects the
correct MSI PTE, without ever deriving a vCPU, or having ever derived a
vCPU or any other per-IRQ state, from the guest IOVA.

This ownership of remapping (for ARM in the ITS and for RISC-V in the
IOMMU) also justifies why ARM does not need an irqdomain in the IOMMU and
RISC-V does.

> 
> Exactly the same as what you want.
> 
> > The guest-selected IOVA must be preserved for S1 while ITS routing
> > is managed separately.  RISC-V performs MSI remapping in the IOMMU
> > after S1, so guest MSI target changes do not require corresponding
> > per-vector coordination with a separate interrupt controller.
> 
> In ARM you'd manage vCPU mapping in the GIC since it is already doing
> translation lookups, this happens without involving the iommu. It
> doesn't need to change the descriptor to do this.
> 
> But conceptually it is the same thing, there is a part along the MSI
> chain that maps from vCPU to pCPU. Either in the GIC HW tables or in
> the IOMMU MSI tables, doesn't matter much, IMHO.

ARM needs the VMM/KVM to track gIOVA-to-vITS mappings so it can program
the physical ITS correctly. RISC-V does not.

> 
> I think the two x86's also have a very similar thing where the iommu
> interrupt remapping tables can do the vCPU to pCPU translation.
> 
> Again nobody has built this and if we do it must somehow be able to
> work generically for all arches, so it will take a while to get it
> sorted out I think. Since riscv's HW design boxed themselves into
> doing all this work I guess you have no choice.
> 
> I strongly recommend you keep it seperate from this initial series
> (And remove the irq domains from this series) and come with a proposal
> that everyone can understand how an arch could hook into all of this
> machinery.

The irqbypass support is already separate from this series. This series
only introduces the IOMMU irqdomain, which owns the IOMMU-specific MSI
composition now and will provide the irq_set_vcpu_affinity() hook needed
later. Putting the compose code in the IMSIC irqdomain now, only to move
it into the IOMMU irqdomain with irqbypass later, would add unnecessary
churn.

The design itself is not especially complex. Most of the current
implementation complexity (locks, RCU, deferred MSI-domain attachment,
etc.) came from maintaining msi_iova[]. Dropping that cache in v5 removes
it.

Thanks,
drew

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv