From: Jason Gunthorpe <jgg@nvidia.com>
To: fangyu.yu@linux.alibaba.com
Cc: gong.shuai@sanechips.com.cn, alex@ghiti.fr,
andrew.jones@oss.qualcomm.com, aou@eecs.berkeley.edu,
gsh517025@gmail.com, guoren@kernel.org, iommu@lists.linux.dev,
joro@8bytes.org, jroedel@suse.de, kvm-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
palmer@dabbelt.com, pjw@kernel.org, robin.murphy@arm.com,
tomasz.jeznach@linux.dev, will@kernel.org, zong.li@sifive.com
Subject: Re: [RFC PATCH v2 3/4] iommu/riscv: Add guest IMSIC GPA mapping helpers
Date: Tue, 27 Oct 2026 11:13:00 -0300 [thread overview]
Message-ID: <20261027141300.GB2338330@nvidia.com> (raw)
In-Reply-To: <20261027140837.84112-1-fangyu.yu@linux.alibaba.com>
On Tue, Oct 27, 2026 at 10:08:37PM +0800, fangyu.yu@linux.alibaba.com wrote:
> >His concern seems to be about who owns and maintains these mappings.
> >When the RISC-V IOMMU driver calls iommu_map directly on a paging
> >domain managed by iommufd, the mappings are not visible to the domain
> >owner. This makes it difficult to handle mapping lifetime and
> >hardware page table replacement correctly.
> >
>
> Hi Shuai,
>
> Thanks for the review.
>
> Before going further, I want to make sure I answer the actual
> question. If the concern is about who owns and maintains these
> mappings, I address that below.
>
> The iommu_map() and replace_leaf() calls are not a separate
> mapping facility added next to the forwarding code. They are
> two steps in the existing interrupt-forwarding state machine
> driven from iommu-ir.c:
>
> - first FORWARD: flat -> MSIPTE written /
> noflat -> S2 PTE installed
> - UPDATE_TARGET: flat -> MSIPTE updated /
> noflat -> replace_leaf()
> (only if the VS-file page moved)
> - last unforward: flat -> MSI table deactivated /
> noflat -> S2 PTE removed
>
> So the lifetime of the S2 mapping matches the lifetime of the
> forwarding session, which is the same rule the MSI page table
> already follows. The driver is the only layer that sees both
> the forwarding session (device <-> vCPU) and the paging domain
> used to translate guest MSI writes, so it is also the only
> layer that can maintain this mapping.
>
> Note that the noflat column of the last row is not in v2: v2
> only frees the bookkeeping when the domain is torn down. In
> v3, I revoke the S2 entries both when the last forwarded IRQ
> in the domain is released and at domain free, so the entry
> lifetime becomes identical to the MSIPTE lifetime.
The big point is interrupt code has to live in an irq_domain, not in
the iommu driver, and the IOVA allocator is not part of either irq or
iommu drivers.
So you have to layer this properly if you are going to even attempt
it. It sounds complicated.
Jason
next prev parent reply other threads:[~2026-10-27 14:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 14:11 [RFC PATCH v2 0/4] iommu/riscv: Add irqbypass support without MSI page table fangyu.yu
2026-10-14 14:11 ` [RFC PATCH v2 1/4] iommupt: Add replace_leaf to atomically swap a leaf OA fangyu.yu
2026-10-14 14:11 ` [RFC PATCH v2 2/4] iommu/riscv: Extract IRQ forwarding payload validation fangyu.yu
2026-10-14 14:11 ` [RFC PATCH v2 3/4] iommu/riscv: Add guest IMSIC GPA mapping helpers fangyu.yu
2026-10-15 23:47 ` Jason Gunthorpe
2026-10-16 3:01 ` fangyu.yu
2026-10-26 8:06 ` Gong Shuai
2026-10-27 14:08 ` fangyu.yu
2026-10-27 14:13 ` Jason Gunthorpe [this message]
2026-10-14 14:11 ` [RFC PATCH v2 4/4] iommu/riscv: Support IRQ forwarding without MSI page tables fangyu.yu
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=20261027141300.GB2338330@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex@ghiti.fr \
--cc=andrew.jones@oss.qualcomm.com \
--cc=aou@eecs.berkeley.edu \
--cc=fangyu.yu@linux.alibaba.com \
--cc=gong.shuai@sanechips.com.cn \
--cc=gsh517025@gmail.com \
--cc=guoren@kernel.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=kvm-riscv@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=robin.murphy@arm.com \
--cc=tomasz.jeznach@linux.dev \
--cc=will@kernel.org \
--cc=zong.li@sifive.com \
/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
all inboxes | Powered by JetHome®