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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Sep 23, 2025 at 10:12:42AM -0500, Andrew Jones wrote:
> be able to reach be reachable by managing the IOMMU MSI table. This gives
> us some level of isolation, but there is still the possibility a device
> may raise an interrupt it should not be able to when its irqs are affined
> to the same CPU as another device's

Yes, exactly, this is the problem with basic VFIO support as there is
no general idea of a virtualization context..

> and the malicious/broken device uses the wrong MSI data.

And to be clear it is not a malicious/broken device at issue here. In
PCI MSI is simple a DMA to a magic address. *ANY* device can be
commanded by system software to generate *ANY* address/data on PCIe.

So any VFIO user can effectively generate any MSI it wants. It isn't a
matter of device brokeness.

> near isolated enough. However, for the virt case, Addr is set to guest
> interrupt files (something like virtual IMSICs) which means there will be
> no other host device or other guest device irqs sharing those Addrs.
> Interrupts for devices assigned to guests are truly isolated (not within
> the guest, but we need nested support to fully isolate within the guest
> anyway).

At least this is something, and I do think this is enough security to
be a useful solution. However, Linux has no existing support for the
idea of a VFIO device that only has access to "guest" interrupt HW.

Presumably this is direct injection only now?

I'm not even sure I could give you a sketch what that would look like,
it involves co-operation between so many orthogonal layers it is hard
to imagine :\

kvm provides the virt context, iommufd controls the MSI aperture, irq
remapping controls the remap table, vfio sets interrupts..

VFIO needs to say 'irq layer only establish an interrupt on this KVM'
as some enforced mode ?

Jason