From: Dave Jiang <dave.jiang@intel.com>
To: Koichiro Den <den@valinux.co.jp>, Jon Mason <jdmason@kudzu.us>,
Allen Hubbe <allenbh@gmail.com>, Frank Li <Frank.Li@nxp.com>
Cc: Niklas Cassel <cassel@kernel.org>,
ntb@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] NTB: Allow drivers to provide DMA mapping device
Date: Mon, 2 Mar 2026 09:52:08 -0700 [thread overview]
Message-ID: <3ddba488-6577-4f04-8a50-d64850b7cc5b@intel.com> (raw)
In-Reply-To: <20260302144522.750620-1-den@valinux.co.jp>
On 3/2/26 7:45 AM, Koichiro Den wrote:
> Some NTB implementations are backed by a "virtual" PCI device, while the
> actual DMA mapping context (IOMMU domain) belongs to a different device.
>
> One example is vNTB, where the NTB device is represented as a virtual
> PCI endpoint function, but DMA operations must be performed against the
> EPC parent device, which owns the IOMMU context.
>
> Today, ntb_transport implicitly relies on the NTB device's parent device
> as the DMA mapping device. This works for most PCIe NTB hardware, but
> breaks implementations where the NTB PCI function is not the correct
> device to use for DMA API operations.
Actually it doesn't quite work. This resulted in 061a785a114f ("ntb: Force
physically contiguous allocation of rx ring buffers"). As you can see it
tries to get around the issue as a temp measure. The main issue is the
memory window buffer is allocated before the dmaengine devices are allocated.
So the buffer is mapped against the NTB device rather than the DMA device.
So I think we may need to come up with a better scheme to clean up this
issue as some of the current NTBs can utilize this change as well.
The per queue DMA device presents an initialization hierarchy challenge with the
memory window context. I'm open to suggestions.
DJ
>
> This small series introduces an optional .get_dma_dev() callback in
> struct ntb_dev_ops, together with a helper ntb_get_dma_dev(). If the
> callback is not implemented, the helper falls back to the existing
> default behavior. Drivers that implement .get_dma_dev() must return a
> non-NULL struct device.
>
> - Patch 1/2: Add .get_dma_dev() to struct ntb_dev_ops and provide
> ntb_get_dma_dev().
>
> - Patch 2/2: Switch ntb_transport coherent allocations and frees to use
> ntb_get_dma_dev().
>
> No functional changes are intended by this series itself.
>
> A follow-up patch implementing .get_dma_dev() for the vNTB EPF driver
> (drivers/pci/endpoint/functions/pci-epf-vntb.c) will be submitted
> separately to the PCI Endpoint subsystem tree. That will enable
> ntb_transport to work correctly in IOMMU-backed EPC setups.
>
> Best regards,
> Koichiro
>
>
> Koichiro Den (2):
> NTB: core: Add .get_dma_dev() callback to ntb_dev_ops
> NTB: ntb_transport: Use ntb_get_dma_dev() for DMA buffers
>
> drivers/ntb/ntb_transport.c | 14 +++++++-------
> include/linux/ntb.h | 23 +++++++++++++++++++++++
> 2 files changed, 30 insertions(+), 7 deletions(-)
>
next prev parent reply other threads:[~2026-03-02 16:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 14:45 [PATCH 0/2] NTB: Allow drivers to provide DMA mapping device Koichiro Den
2026-03-02 14:45 ` [PATCH 1/2] NTB: core: Add .get_dma_dev() callback to ntb_dev_ops Koichiro Den
2026-03-02 14:45 ` [PATCH 2/2] NTB: ntb_transport: Use ntb_get_dma_dev() for DMA buffers Koichiro Den
2026-03-02 16:52 ` Dave Jiang [this message]
2026-03-03 4:56 ` [PATCH 0/2] NTB: Allow drivers to provide DMA mapping device Koichiro Den
2026-03-03 15:42 ` Dave Jiang
2026-03-04 15:56 ` Koichiro Den
2026-03-04 16:03 ` Koichiro Den
2026-03-04 16:53 ` Dave Jiang
2026-03-05 3:23 ` Koichiro Den
2026-03-05 16:32 ` Dave Jiang
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=3ddba488-6577-4f04-8a50-d64850b7cc5b@intel.com \
--to=dave.jiang@intel.com \
--cc=Frank.Li@nxp.com \
--cc=allenbh@gmail.com \
--cc=cassel@kernel.org \
--cc=den@valinux.co.jp \
--cc=jdmason@kudzu.us \
--cc=linux-kernel@vger.kernel.org \
--cc=ntb@lists.linux.dev \
/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