All of lore.kernel.org
 help / color / mirror / Atom feed
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

-- 
kvm-riscv mailing list
kvm-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kvm-riscv

WARNING: multiple messages have this Message-ID (diff)
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

WARNING: multiple messages have this Message-ID (diff)
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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-10-16 14:25 UTC|newest]

Thread overview: 63+ 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 ` Gong Shuai
2026-10-15  6:52 ` 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   ` Gong Shuai
2026-10-15  6:52   ` 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  6:52   ` Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15 23:54   ` Jason Gunthorpe
2026-10-15 23:54     ` Jason Gunthorpe
2026-10-15 23:54     ` Jason Gunthorpe
2026-10-16  7:30     ` Gong Shuai
2026-10-16  7:30       ` Gong Shuai
2026-10-16  7:30       ` Gong Shuai
2026-10-16 15:00       ` Jason Gunthorpe
2026-10-16 15:00         ` Jason Gunthorpe
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   ` Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15  6:52 ` [RFC PATCH 04/12] iommu/riscv: Add vIOMMU object support Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15  6:52 ` [RFC PATCH 05/12] iommu/riscv: Add nested domain allocation Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15  6:52 ` [RFC PATCH 06/12] iommu/riscv: Add vIOMMU cache invalidation Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15  6:52 ` [RFC PATCH 07/12] iommufd: Add RISC-V IOMMU hardware info type Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-15 23:55   ` Jason Gunthorpe
2026-10-15 23:55     ` Jason Gunthorpe
2026-10-15 23:55     ` Jason Gunthorpe
2026-10-16  7:43     ` Gong Shuai
2026-10-16  7:43       ` Gong Shuai
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   ` Gong Shuai
2026-10-15  6:52   ` 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   ` Gong Shuai
2026-10-15  6:52   ` 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   ` Gong Shuai
2026-10-15  6:52   ` 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   ` Gong Shuai
2026-10-15  6:52   ` 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-15  6:52   ` Gong Shuai
2026-10-15  6:52   ` Gong Shuai
2026-10-16  0:00 ` [RFC PATCH 0/12] iommu/riscv: Add nested translation (vIOMMU) support Jason Gunthorpe
2026-10-16  0:00   ` Jason Gunthorpe
2026-10-16  0:00   ` Jason Gunthorpe
2026-10-16  9:16   ` Gong Shuai
2026-10-16  9:16     ` Gong Shuai
2026-10-16  9:16     ` Gong Shuai
2026-10-16 14:25     ` Jason Gunthorpe [this message]
2026-10-16 14:25       ` Jason Gunthorpe
2026-10-16 14:25       ` Jason Gunthorpe

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.