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

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.

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

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.

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

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

Jason

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