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

On Tue, Aug 25, 2026 at 06:14:55PM +0200, Andrew Jones wrote:
> On Tue, Aug 25, 2026 at 11:03:34AM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 25, 2026 at 03:24:01PM +0200, Andrew Jones wrote:
> > 
> > > The irqdomains remain per-device. The MSI table belongs to the
> > > corresponding S2 IOMMU domain and its configuration is bound to one VM's
> > > IMSIC topology. The current prototype rejects irqbypass from another VM
> > > once the table has an owner. The irqdomain does not sit on top of the
> > > vIOMMUs. A vIOMMU links guest-controlled S1 domains to their S2 parent,
> > > while the per-device irqdomain is the IRQ-side entry point for updating
> > > that parent's MSI table.
> > 
> > Doesn't sound like the right design to me. Pretending it is not bound
> > to the S2 just to make it global then blocking multi-VM is not a good
> > place to start from.
> 
> The MSI table fields are part of the IOMMU device context, and the
> device's irqdomain is how IRQ operations reach the IOMMU driver. The
> table storage is owned by the S2 domain so all devices attached to that
> domain use the same mappings. Sharing an S2 domain between VMs would
> also share their DMA address space, so rejecting a different owner for
> the MSI table is only a sanity check, not an expected limitation.

That's not what I'm saying, having one irqdomain controlling two
msitables based on how the iommu happens to be configured, and what
device the IRQ is is using does not seem like a great arrangement in
general.

We have enough problems keeping the iommu and irq layers in sync, now
this is making them even more split. It makes more sense to me if the
irqdomain has a singular msitable and the iommu progams that into the
device context, not the other way around. This of course implies that
each vm gets its own irqdomain plus table and all its VFIO devices are
joined to it.

This seems broadly similar to the other arches where you do want to
have some kind of per-vm control point that the VFIO devices are
bundled into that programs the remapping HW for that slice of the
system.

IDK what Thomas thinks..

> > And this is an entirely different thing, you don't need a domain just
> > to call irq_compose_msi_msg()..
> 
> The IOMMU irqdomain does not merely call irq_compose_msi_msg(). It
> implements that callback to perform host MSI remapping. Without this
> layer, that remapping logic would have to be put in the IMSIC driver,
> where it does not belong.

You've lost me there, the host does not use the msi table so what
remapping logic is there?

Jason

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