[PATCH 1/2] iommu/riscv: Map IMSIC addresses for paging domains
Jason Gunthorpe
jgg at nvidia.com
Tue May 12 09:33:13 PDT 2026
On Tue, May 12, 2026 at 11:22:46AM -0500, Andrew Jones wrote:
> > > + /*
> > > + * The device always writes to the host physical IMSIC address, so install
> > > + * identity mappings directly. Use IOMMU_RESV_DIRECT_RELAXABLE instead of
> > > + * IOMMU_RESV_DIRECT since these 1:1 mappings are not required for assigned
> > > + * devices.
> >
> > Oh? Why not?
>
> Hi Jason,
>
> I should change the comment above to be stronger. 'not required' sounds
> like a choice is being made, but guest devices must not have mappings to
> host IMSICs - that would break their isolation.
VFIO is more that virtualization and it is certainly required to have
these mapping to operate interrupts in normal non virtualization VFIO
cases.
> RISC-V AIA has the concept of guest interrupt files. Assigned devices must
> write the addresses of those interrupt files to deliver MSIs to guest
> IMSICs (virtual IMSICs). Also, the VMM can map the virtual IMSICs where it
> likes, which will not necessarily be the same addresses the host IMSICs
> use. We need the irqbypass series I'm working on for guests, not these
> direct mappings.
I remember going over this and it was decided it couldn't do the MSI
security so it was in trouble..
And mapping the virtual IMSICs is problematic too, ARM has the same
issue with its ITS page that we never solved.
The proper comment is using IOMMU_RESV_DIRECT_RELAXABLE causes
interrupts to be unavailable to VFIO in the normal ways which I think
is not acceptable for an IOMMU driver.
> > > + reg = iommu_alloc_resv_region(local->msi_pa, IMSIC_MMIO_PAGE_SZ,
> > > + IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO,
> > > + IOMMU_RESV_DIRECT_RELAXABLE, GFP_KERNEL);
> > > + if (reg)
> > > + list_add_tail(®->list, head);
> >
> > This seems like quite a hack, the ARM was seems much better, the
> > interrupt controller should be using the iommu_dma_prepare_msi() path
> > to obtain an appropriately translated MSI address for the aperture.
>
> The difference between ARM and RISC-V is that on RISC-V each CPU has an
> IMSIC and the device will target any one of them, depending on its current
> affinity (i.e. the MSI target changes with irq-set-affinity). ARM has a
> single doorbell address which has a single IOVA->PA mapping created for
> it that never changes. The ITS manages everything, including affinity
> changes. Even when I get an IR irqdomain posted that implements
> irq-set-affinity to help further isolate devices on the host, we'll still
> want get_resv to pre-create these direct mappings since we can't
> create/alloc them at irq-set-affinity time which runs in atomic context.
You'd have to use the iommu_dma_prepare_msi() path to pre-create all
the IMSIC mappings when the IRQ is first attached.
The reserved regions were supposed to come from FW. The API path to
connect the irq driver to the iommu is through
iommu_dma_prepare_msi().
If you mix them up like this then your VFIO is broken.
Jason
More information about the linux-riscv
mailing list