From: Jason Gunthorpe <jgg@ziepe.ca>
To: Gong Shuai <gong.shuai@sanechips.com.cn>
Cc: alex@ghiti.fr, andrew.jones@oss.qualcomm.com,
anup@brainfault.org, aou@eecs.berkeley.edu,
atish.patra@linux.dev, fangyu.yu@linux.alibaba.com,
gsh517025@gmail.com, iommu@lists.linux.dev, joro@8bytes.org,
kevin.tian@intel.com, kvm-riscv@lists.infradead.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, palmer@dabbelt.com,
pbonzini@redhat.com, pjw@kernel.org, robin.murphy@arm.com,
seanjc@google.com, tomasz.jeznach@linux.dev, will@kernel.org,
wu.fei9@sanechips.com.cn, zhao.qingye@sanechips.com.cn
Subject: Re: [RFC PATCH 0/12] iommu/riscv: Add nested translation (vIOMMU) support
Date: Fri, 16 Oct 2026 11:25:35 -0300 [thread overview]
Message-ID: <20261016142535.GD14213@ziepe.ca> (raw)
In-Reply-To: <20261016091610.13912-1-gong.shuai@sanechips.com.cn>
On Fri, Oct 16, 2026 at 05:16:10PM +0800, Gong Shuai wrote:
> Hi Jason,
>
> Thanks for the review again.
>
> > > Add nested translation support to the RISC-V IOMMU driver, so a KVM guest
> > > with its own vIOMMU can own the first stage of a device context while the
> > > host keeps the second stage, and add the interrupt support. This is an RFC
> > > and comments on the design are welcome.
> >
> > The iommufd parts looked reasonable to me
> >
> > I feel some mild skepticism about all the MSI parts, it would be good
> > to get more of the interrupt stuff actually landed before posting this
> > again.
>
> Agreed on the MSI parts. They are a working proof to exercise the
> nested flow end to end, not a finished design. The reason they are
> in this series at all is that the NVMe device we use for testing
> depends on MSI interrupts. Without this support, DMA succeeds but
> the MSIs fault, so the driver ends up polling for completions after
> timeouts.
>
> We will keep following the irqbypass groundwork as it evolves, and
> continue this work once it has landed.
It seems to me the riscv interrupt architecture is a terrible fit for
Linux, so I would prefer you keep that out of a viommu series and try
to address interrupt support in VFIO through the other series.
viommu shouldn't change anything about how interrupts work..
Without the msi stuff I think you could get this merged without a big
trouble.
Jason
prev parent reply other threads:[~2026-10-16 14:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 6:52 [RFC PATCH 0/12] iommu/riscv: Add nested translation (vIOMMU) support Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 01/12] iommu/riscv: Use DC.tc.V as the device context valid bit Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 02/12] iommufd: Add RISC-V IOMMU hwpt and vIOMMU types Gong Shuai
2026-10-15 23:54 ` Jason Gunthorpe
2026-10-16 7:30 ` Gong Shuai
2026-10-16 15:00 ` Jason Gunthorpe
2026-10-15 6:52 ` [RFC PATCH 03/12] iommufd: Add RISC-V IOMMU cache invalidation data type Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 04/12] iommu/riscv: Add vIOMMU object support Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 05/12] iommu/riscv: Add nested domain allocation Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 06/12] iommu/riscv: Add vIOMMU cache invalidation Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 07/12] iommufd: Add RISC-V IOMMU hardware info type Gong Shuai
2026-10-15 23:55 ` Jason Gunthorpe
2026-10-16 7:43 ` Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 08/12] iommu/riscv: Add riscv_iommu_hw_info Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 09/12] iommu/riscv: Add riscv_iommu_attach_dev_nested Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 10/12] RISC-V: KVM: Accept auto-mode interrupt files for IMSIC IRQ bypass Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 11/12] iommu/riscv: Accept unpublished interrupt files in IRQ forwarding Gong Shuai
2026-10-15 6:52 ` [RFC PATCH 12/12] RISC-V: KVM: Forward MSIs for guests with a vIOMMU Gong Shuai
2026-10-16 0:00 ` [RFC PATCH 0/12] iommu/riscv: Add nested translation (vIOMMU) support Jason Gunthorpe
2026-10-16 9:16 ` Gong Shuai
2026-10-16 14:25 ` Jason Gunthorpe [this message]
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=20261016142535.GD14213@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alex@ghiti.fr \
--cc=andrew.jones@oss.qualcomm.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@linux.dev \
--cc=fangyu.yu@linux.alibaba.com \
--cc=gong.shuai@sanechips.com.cn \
--cc=gsh517025@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pbonzini@redhat.com \
--cc=pjw@kernel.org \
--cc=robin.murphy@arm.com \
--cc=seanjc@google.com \
--cc=tomasz.jeznach@linux.dev \
--cc=will@kernel.org \
--cc=wu.fei9@sanechips.com.cn \
--cc=zhao.qingye@sanechips.com.cn \
/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