From: Jason Gunthorpe <jgg@nvidia.com>
To: Andrew Jones <andrew.jones@oss.qualcomm.com>
Cc: linux-riscv@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, tjeznach@rivosinc.com,
joro@8bytes.org, will@kernel.org, pjw@kernel.org,
palmer@dabbelt.com, anup@brainfault.org
Subject: Re: [PATCH 1/2] iommu/riscv: Map IMSIC addresses for paging domains
Date: Tue, 12 May 2026 13:33:13 -0300 [thread overview]
Message-ID: <20260512163313.GC7655@nvidia.com> (raw)
In-Reply-To: <eiikdvzbjffmsnejcsmpv34ljo5afurz2m7g4do6jxrrpkhnes@dsfruyaccvkh>
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
next prev parent reply other threads:[~2026-05-12 16:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 21:23 [PATCH 0/2] iommu/riscv: Enable IOMMU_DMA Andrew Jones
2026-05-08 21:23 ` [PATCH 1/2] iommu/riscv: Map IMSIC addresses for paging domains Andrew Jones
2026-05-09 2:21 ` fangyu.yu
2026-05-09 19:47 ` Andrew Jones
2026-05-10 14:40 ` fangyu.yu
2026-05-12 13:38 ` Jason Gunthorpe
2026-05-12 16:22 ` Andrew Jones
2026-05-12 16:33 ` Jason Gunthorpe [this message]
2026-05-12 17:21 ` Tomasz Jeznach
2026-05-08 21:23 ` [PATCH 2/2] iommu/dma: enable IOMMU_DMA for RISC-V Andrew Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260512163313.GC7655@nvidia.com \
--to=jgg@nvidia.com \
--cc=andrew.jones@oss.qualcomm.com \
--cc=anup@brainfault.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=tjeznach@rivosinc.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox