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

[Vincent Chen]

On Wed, Sep 24, 2025 at 12:34 AM Andrew Jones <ajones@xxxxxxxxxxxxxxxx> 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?

> >
> > The direct injection interrupt path is already quite a confusing
> > thing..
>
> No argument there :-)
>
> Thanks,
> drew
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-riscv