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

On Mon, Aug 24, 2026 at 02:04:17PM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 24, 2026 at 05:43:19PM +0200, Andrew Jones wrote:
> 
> > VFIO cannot silently switch back to host delivery. We need plumbing
> > to establish a guest-owned MSI mode, preserve and mask the guest
> > descriptor across the VFIO vector lifecycle, and stop or reject the
> > configuration if that mode cannot be maintained.
> 
> Yeah
> 
> > The guest descriptor itself is already available in
> > kvm_arch_update_irqfd_routing(), so RISC-V still does not need to
> > interpret or track the guest IOVA. The IOVA can be written directly to the
> > device (since the IOMMU MSI table is pre-populated with all vIMSIC GPAs).
> 
> Yeah, and now you are getting in "fun" land about how should
> information KVM has get shared with the IRQ subsystem and irqdomains
> (?)  that need to use it to make decisions.

The interface we have is irq_set_vcpu_affinity(), which is a bit messy
to use for everything. ARM uses it as a command interface
(enum its_vcpu_info_cmd_type), and the RISC-V irqbypass prototype is
currently following that example.

> 
> > Indeed, irq_set_vcpu_affinity() alone will be insufficient for two-stage
> > guests due to the VFIO vector lifecycle concerns with guest-owned MSI
> > descriptors.
> > 
> > RISC-V does not need S2 page-table mappings for MSIs, though. The VM's
> > IMSIC topology identifies the vIMSIC GPAs used to populate the MSI table,
> > and an MSI-table match bypasses the normal S2 page table.
> 
> Okay, so that's an odd twist, you won't need to get the physical into
> the S2 then, but the VMM does need to reserve off a hole in the S2 for
> the MSI table to land and manipulate the physical through a parallel
> translation mechanism.

I don't think we even need a hole. If, after S1, a GPA matches the MSI
address pattern, then the MSI table completes the translation. If the
GPA does not match the pattern then it goes to S2. The VMM already
reserves the vIMSIC GPA range as MMIO, but it doesn't need S2 mappings.

> 
> Then that means if an irqdomain wraps this translation it is actually
> a *per VM* domain with a *per VM* translation, sitting on top of a
> bunch of iommufd viommus, somehow. That's feeling pretty weird now.

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.

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().

> 
> > I agree there is some new terrain to travel here. It'd be great to discuss
> > this at Plumber's.
> 
> I would still try to get basic baseline support landed for a 'bare'
> translation using a RMR (?). That doesn't require any new inventions
> at least.

Working on it :-)

> 
> Then the question of how to support a S1, guest controlled descriptor,
> and per-vm vCPU to pCPU remapping table can be clearly articulated..
> 

Thanks,
drew

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