[RFC PATCH v2 08/18] iommu/riscv: Use MSI table to enable IMSIC access

[Andrew Jones]

On Tue, Mar 24, 2026 at 05:12:26PM +0800, Vincent Chen wrote:
> On Wed, Sep 24, 2025 at 12:34 AM Andrew Jones <ajones at ventanamicro.com> wrote:
> >
> > On Tue, Sep 23, 2025 at 01:23:02PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Sep 23, 2025 at 10:50:56AM -0500, Andrew Jones wrote:
> > > > Yes, this is the part that I'd like to lean on you for, since I understand
> > > > we want to avoid too much KVM/virt special casing for VFIO/IOMMUFD. I was
> > > > thinking that if I bit the bullet and implemented nested support than when
> > > > nesting was selected it would be apparent we're in virt context. However,
> > > > I was hoping to pull together a solution that works with current QEMU and
> > > > VFIO too.
> > >
> > > You probably do have to make nested part of this, but I don't have a
> > > clear picture how you'd tie all the parts together through the nested
> > > API..
> > >
> > > Somehow you have to load a msiptp that is effectively linked to the
> > > KVM reliably into the DC for the iommufd controlled devices that are
> > > linked to that KVM. Then synchronize with VFIO that this is done and
> > > it can setup KVM only interrupts somehow. This kvm entanglement is the
> > > "virt" you have mentioned many times.
> >
> > Yes, the VFIO+KVM irqbypass framework currently provides much of this
> > support (which patches 10-17 of this series leverage). But, if using
> > nested is necessary in order to "signal" to the relevant subsystems that
> > the device's irqs will truly be isolated, then I'll need to start figuring
> > out how iommufd can fit into the mix (or if we'll need an iommufd-specific
> > implementation for a new mix).
> >
> 
> Hi Andrew and Jason,
> 
> I just noticed this thread, so apologies if I missed any prior context
> or if this has already been discussed.
> 
> If I understand correctly, the current discussion revolves around
> using nested translation to identify a safe "Virt Context" for VFIO,
> largely because the base RISC-V IOMMU/IMSIC doesn't validate MSI data,
> leaving non-virt cases vulnerable to MSI spoofing.
> 
> I'd like to share an alternative idea and see if it might be a viable
> direction for this scenario.
> 
> As Andrew mentioned, sharing the same IMSIC file without data
> validation makes it difficult to prevent spoofing. However, what if we
> consider utilizing the MRIF (Message Request Interface File) feature
> for VFIO passthrough devices?
> 
> While MRIF is primarily designed to extend the number of guest IMSICs,
> the specification doesn't seem to limit its usage strictly to the Virt
> Context. If we assign a dedicated MRIF to a passthrough device (even
> for non-virt/userspace cases), the device would only be able to send
> MSIs to its own isolated MRIF via the IOMMU MSI table.
> 
> In this setup, the actual interrupt delivered to the physical CPU
> would be the Notice MSI generated by the IOMMU hardware itself. Since
> the address and data of this Notice MSI are strictly configured by the
> Host OS, the device wouldn't be able to spoof MSIs to the Host or
> other devices.
> 
> If my understanding is correct, this approach might naturally provide
> the isolation needed for IRQ_DOMAIN_FLAG_ISOLATED_MSI across both virt
> and non-virt contexts, potentially simplifying the need for KVM/VFIO
> special casing.
> 
> I wonder if this approach would be acceptable, or if there are any
> hardware/software constraints I might have overlooked?
>

Hi Vincent,

Thank you for your thoughts on this. I agree that using MRIFs would
allow IRQ_DOMAIN_FLAG_ISOLATED_MSI to be set. Indeed that may be the
best we can currently do for userspace device assignment. For guest
device assignment we can already do something similar by simply not
implementing irqbypass at all (VFIO without irqbypass does essentially
the same thing).

I plan to post another version of this series which will only use the
MSI table for guests, since I need g-stage to not be Bare in order to
enable the MSI table anyway, but we don't want to unnecessarily mess
with g-stage for non-virt uses.

Thanks,
drew