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

On Fri, Aug 21, 2026 at 02:20:15PM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 21, 2026 at 07:12:15PM +0200, Andrew Jones wrote:
> > > Does riscv absolutely require this? I suppose you have a new problem
> > > where you don't know what affinity the guest is selecting when it
> > > provides a MSI-X addr as you don't know what physical IMSIC page is
> > > under its S1 IOVA?
> > 
> > The IOMMU MSI table operates after S1, so it matches the resulting IMSIC
> > GPA. With a vIOMMU, the guest may use any MSI IOVA that its S1 maps to
> > that GPA. With S1 Bare, the device uses the GPA directly. In either case
> > the hypervisor provides the guest IMSIC topology and the guest interrupt
> > file or MRIF target needed to program the MSI table (through the IRQ
> > domain).
> 
> I suspect you should have an IRQ domain for the msiptp functionality,
> but IDK what it should do... Is this basically to remap vCPUs to
> pCPUs?

Yes, basically, it controls the mappings of the vIMSIC GPAs (which are
per-vCPU) to the guest interrupt files and MRIFs. Guest interrupt files
are pCPU resources that the hypervisor manages and MRIFs (memory resident
interrupt files) are just RAM that the hypervisor manages.

> 
> The viommu can set the msi_addr_pattern

msi_addr_pattern should be under the control of the hypervisor since
it, and its companion msi_addr_mask, represent a block of GPAs. It
will necessarily have to match the vIMSIC topology described by the
VMM to work anyway.

> 
> The existing msi stuff can place the physical ICMC at the right spot
> in the S1 to give to the viommu (Nicolin's series may be needed for
> this too, I forget)
> 
> Not sure how you provide the guest MSI descriptor and have the irq
> layer program it directly..
> 
> It is unfortunate you can't learn the vCPU the MSI is targetting from
> the MSI descriptor, in terms of linux that's a pretty difficult choice
> to implement.
>

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. If all vIMSIC GPAs are pre-mapped in the MSI
table, S1 can map any guest-selected IOVA to any vIMSIC GPA:

  Guest IOVA -> S1 -> vIMSIC GPA -> MSI table -> VS-file or MRIF

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.

As I understand it, Nicolin's series addresses the ARM split between
SMMU translation and ITS interrupt remapping. 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.

Thanks,
drew

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