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

[Andrew Jones]

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.

> 
> It needs a design where the guest remap is linked to the viommu so it
> can be per-vm, somehow.
> 
> > For the host remapping implemented by this series, each irqdomain is
> > per-device because it is inserted into the device's IRQ hierarchy and
> > provides MSI remapping through irq_compose_msi_msg().
> 
> 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.

Thanks,
drew