Linux PCI Non-Transparent Bridge framework and drivers
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Koichiro Den" <den@valinux.co.jp>
Cc: linux-pci@vger.kernel.org, ntb@lists.linux.dev
Subject: Re: [PATCH v7 06/10] PCI: endpoint: pci-epf-vntb: Allow DMA and MW to share a BAR
Date: Wed, 21 Oct 2026 04:43:38 +0000	[thread overview]
Message-ID: <sashiko-outbox-179793@kernel.org> (raw)
In-Reply-To: <20261021042229.2280937-7-den@valinux.co.jp>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] PCI: pci-epf-vntb: wrong alignment reporting in vntb_epf_mw_get_align()
- [Medium] PCI: pci-epf-vntb: unaligned MW offset in epf_ntb_dw_edma_collect()
- [Medium] PCI: pci-epf-vntb: broken BAR validation in epf_ntb_dw_edma_collect()
--

commit 79eb04af128c16e4dcc089f5decfc0f781ca41df
Author: Koichiro Den <den@valinux.co.jp>

PCI: endpoint: pci-epf-vntb: Allow DMA and MW to share a BAR

This commit allows the endpoint DMA BAR (dma_bar) to share a BAR with a
memory window by placing the DMA submap regions after the configured MW
region. It also updates MW alignment reporting and requires the host to
advertise MW/DMA boundary support during LINK_UP.

> diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c
> index ac83af54122f7..721cd841a1dd8 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c

[ ... ]

> @@ -229,6 +230,22 @@ static bool epf_ntb_is_bar_used(struct epf_ntb *ntb,
>  	return false;
>  }
>  
> +static u64 epf_ntb_dma_bar_offset(struct epf_ntb *ntb, enum pci_barno barno)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < ntb->num_mws; i++)
> +		if (ntb->epf_ntb_bar[BAR_MW1 + i] == barno)
> +			return ntb->mws_size[i];
> +
> +	return 0;
> +}
> +
> +static bool epf_ntb_dma_shares_bar(struct epf_ntb *ntb, enum pci_barno barno)
> +{
> +	return ntb->dma && ntb->epf_ntb_bar[BAR_DMA] == barno;
> +}
> +
>  struct epf_ntb_dma_filter {
>  	struct device *dev;
>  	int chan_id;
> @@ -353,6 +370,7 @@ static int epf_ntb_dw_edma_collect(struct epf_ntb *ntb,
>  	unsigned int i;
>  	size_t align;
>  	u32 next = 0;
> +	u64 offset;
>  	int ret;
>  
>  	if (ctrl->u.dma_ctrl.reg_layout_data != EDMA_MF_EDMA_UNROLL)
> @@ -371,9 +389,30 @@ static int epf_ntb_dw_edma_collect(struct epf_ntb *ntb,
>  	if (!is_power_of_2(align))
>  		return -EINVAL;
>  
> -	if (epf_ntb_is_bar_used(ntb, barno) ||
> -	    pci_epc_get_next_free_bar(features, barno) != barno)
> +	if (barno == ntb->epf_ntb_bar[BAR_CONFIG] ||
> +	    barno == ntb->epf_ntb_bar[BAR_DB])
> +		return -EINVAL;
> +
> +	offset = epf_ntb_dma_bar_offset(ntb, barno);
> +	if (!offset &&
> +	    (epf_ntb_is_bar_used(ntb, barno) ||
> +	     pci_epc_get_next_free_bar(features, barno) != barno))
> +		return -EINVAL;

[Severity: Medium]
When a shared BAR is configured (offset != 0), gating
pci_epc_get_next_free_bar(features, barno) != barno under !offset skips the
EPC BAR validity check in epf_ntb_dw_edma_collect().

If both mwX_bar and dma_bar are explicitly configured to the same BAR number
via configfs, epf_ntb_find_bar() skips its loop because
ntb->epf_ntb_bar[bar] is already non-negative:

drivers/pci/endpoint/functions/pci-epf-vntb.c:epf_ntb_find_bar() {
	while (ntb->epf_ntb_bar[bar] < 0) {
		barno = pci_epc_get_next_free_bar(epc_features, barno);
		if (barno < 0)
			break; /* No more BAR available */

		if (ntb->epf_ntb_bar[BAR_DMA] != barno &&
		    !epf_ntb_is_bar_used(ntb, barno))
			ntb->epf_ntb_bar[bar] = barno;

		barno += 1;
	}
}

Because epf_ntb_mw_bar_init() also skips pci_epc_set_bar() when shared is
true, nothing verifies that barno is not BAR_RESERVED, BAR_DISABLED, or an
upper 32-bit slot of a preceding 64-bit BAR. In addition,
epf_ntb_dma_bar_offset() returns the first matching MW size without checking
whether multiple MWs were assigned to the same BAR, and epf_ntb_find_bar()
still skips ntb->epf_ntb_bar[BAR_DMA] when auto-assigning MW BARs.

Should pci_epc_get_next_free_bar(features, barno) != barno be checked
unconditionally in epf_ntb_dw_edma_collect(), and should duplicate MW BAR
assignments and auto-assignment in epf_ntb_find_bar() be handled for shared
BARs?

> +	if (offset > U32_MAX)
> +		return -EOVERFLOW;
> +	if (offset && !is_power_of_2(offset))
>  		return -EINVAL;
> +	dma->ctrl.submap.offset = offset;
> +	next = offset;
> +	if (next) {
> +		/*
> +		 * submap[0] covers the MW prefix. Keep its temporary
> +		 * target at address 0 until the MW translation is
> +		 * installed.
> +		 */
> +		dma->submap[0].size = next;
> +		dma->num_submap = 1;
> +	}

[Severity: Medium]
What happens if offset is a power of two that is smaller than align
(features->align, which is 16 KiB or 64 KiB on several DesignWare PCIe
endpoint controllers)?

In epf_ntb_dw_edma_collect(), offset is checked with is_power_of_2(offset),
but not with IS_ALIGNED(offset, align). If an MW size such as SZ_4K is
configured on an EPC with a 64 KiB region_align, dma->submap[0].size and the
starting BAR offset next for subsequent DMA submaps will not be aligned to
align, and backing_size in epf_ntb_dma_bar_init() will also be unaligned.

When epf_ntb_dma_set_bar() or vntb_epf_mw_set_trans() later calls
epf_ntb_dma_set_bar_locked() -> pci_epc_set_bar(),
dw_pcie_ep_validate_submap() rejects the submap array:

drivers/pci/controller/dwc/pcie-designware-ep.c:dw_pcie_ep_validate_submap() {
	for (i = 0; i < num_submap; i++) {
		size = submap[i].size;

		if (!size)
			return -EINVAL;

		if (!IS_ALIGNED(size, align) || !IS_ALIGNED(off, align))
			return -EINVAL;
}

Could epf_ntb_dw_edma_collect() also check !IS_ALIGNED(offset, align) before
accepting offset?

[ ... ]

> @@ -551,7 +592,7 @@ static int epf_ntb_dma_bar_init(struct epf_ntb *ntb)
>  		return -EOPNOTSUPP;
>  
>  	barno = ntb->epf_ntb_bar[BAR_DMA];
> -	mapped_size = dma->ctrl.submap.size;
> +	mapped_size = dma->ctrl.submap.offset + dma->ctrl.submap.size;
>  	/*
>  	 * Submaps cannot be installed until the host assigns the BAR address.
>  	 * Use address 0 for the temporary BAR Match Mode mapping, as is done

[ ... ]

> @@ -1936,6 +2008,16 @@ static int vntb_epf_mw_set_trans(struct ntb_dev *ndev, int pidx, int idx,
>  	dev = &ndev->dev;
>  	barno = ntb->epf_ntb_bar[BAR_MW1 + idx];
>  	epf_bar = &ntb->epf->bar[barno];
> +	if (epf_ntb_dma_shares_bar(ntb, barno)) {
> +		/* DMA submaps start after the configured MW size. */
> +		if (size != ntb->mws_size[idx])
> +			return -EINVAL;
> +
> +		guard(mutex)(&ntb->dma->lock);
> +
> +		return epf_ntb_dma_set_bar_locked(ntb, &addr);
> +	}
> +
>  	epf_bar->phys_addr = addr;
>  	epf_bar->barno = barno;
>  	epf_bar->size = size;
> @@ -2134,15 +2216,17 @@ static int vntb_epf_mw_get_align(struct ntb_dev *ndev, int pidx, int idx,
>  			resource_size_t *size_max)
>  {
>  	struct epf_ntb *ntb = ntb_ndev(ndev);
> +	enum pci_barno barno = ntb->epf_ntb_bar[BAR_MW1 + idx];
> +	u64 size = ntb->mws_size[idx];
>  
>  	if (addr_align)
>  		*addr_align = SZ_4K;
>  
>  	if (size_align)
> -		*size_align = 1;
> +		*size_align = epf_ntb_dma_shares_bar(ntb, barno) ? size : 1;
>  
>  	if (size_max)
> -		*size_max = ntb->mws_size[idx];
> +		*size_max = size;
>  
>  	return 0;
>  }

[Severity: High]
Can reporting *size_align = size while keeping *addr_align = SZ_4K in
vntb_epf_mw_get_align() cause an oversized inbound BAR mapping or an
unaligned submap physical address in vntb_epf_mw_set_trans()?

In drivers/ntb/ntb_transport.c:ntb_set_mw(), the translation size and the
allocated buffer size are rounded using different alignment values:

	rc = ntb_mw_get_align(nt->ndev, PIDX, num_mw, &xlat_align,
			      &xlat_align_size, NULL);
	if (rc)
		return rc;

	xlat_size = round_up(size, xlat_align_size);
	buff_size = round_up(size, xlat_align);

When the requested size (from the peer's MW size scratchpad or max_mw_size)
is smaller than ntb->mws_size[idx], ntb_set_mw() allocates only buff_size
(rounded to SZ_4K) but calls ntb_mw_set_trans() -> vntb_epf_mw_set_trans()
with xlat_size == ntb->mws_size[idx]. vntb_epf_mw_set_trans() then maps the
full ntb->mws_size[idx] window in dma->submap[0] starting at mw->dma_addr,
exposing memory past the end of the allocated buffer to the remote PCIe host.

Furthermore, when vntb_epf_mw_set_trans() installs addr into
dma->submap[0].phys_addr, dw_pcie_ep_validate_submap() requires
IS_ALIGNED(submap[0].phys_addr, align) where align is features->align. On
controllers where features->align > SZ_4K, buffers allocated by NTB clients
using *addr_align = SZ_4K can fail validation in pci_epc_set_bar() with
-EINVAL.

Should vntb_epf_mw_get_align() ensure *addr_align accounts for both
features->align and the shared MW size requirements?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261021042229.2280937-1-den@valinux.co.jp?part=6

  reply	other threads:[~2026-10-21  4:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21  4:22 [PATCH v7 00/10] PCI: endpoint: Remote DMA support via vNTB Koichiro Den
2026-10-21  4:22 ` [PATCH v7 01/10] PCI: endpoint: Add DMA auxiliary resource metadata Koichiro Den
2026-10-21  4:22 ` [PATCH v7 02/10] PCI: dwc: Expose endpoint DMA resources Koichiro Den
2026-10-21  4:38   ` sashiko-bot
2026-10-21  4:22 ` [PATCH v7 03/10] PCI: endpoint: pci-epf-vntb: Move epf_ntb_is_bar_used() up Koichiro Den
2026-10-21  4:22 ` [PATCH v7 04/10] PCI: endpoint: Add pci-epf-ntb.h for the shared NTB control layout Koichiro Den
2026-10-21  4:22 ` [PATCH v7 05/10] PCI: endpoint: pci-epf-vntb: Export endpoint DMA channels Koichiro Den
2026-10-21  4:47   ` sashiko-bot
2026-10-21  4:22 ` [PATCH v7 06/10] PCI: endpoint: pci-epf-vntb: Allow DMA and MW to share a BAR Koichiro Den
2026-10-21  4:43   ` sashiko-bot [this message]
2026-10-21 15:52   ` Frank Li
2026-10-21 16:35     ` Koichiro Den
2026-10-21 19:00       ` Frank Li
2026-10-22  5:08         ` Koichiro Den
2026-10-21  4:22 ` [PATCH v7 07/10] Documentation: PCI: endpoint: Document vNTB DMA export Koichiro Den
2026-10-21  4:22 ` [PATCH v7 08/10] NTB: ntb_hw_epf: Use the shared NTB control layout Koichiro Den
2026-10-21 15:53   ` Frank Li
2026-10-21  4:22 ` [PATCH v7 09/10] NTB: ntb_hw_epf: Discover vNTB-embedded DMA Koichiro Den
2026-10-21  4:22 ` [PATCH v7 10/10] NTB: ntb_hw_epf: Support DMA and MW sharing a BAR Koichiro Den
2026-10-21 15:58   ` Frank Li
2026-10-21 16:57     ` Koichiro Den
2026-10-21 18:51       ` Frank Li

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=sashiko-outbox-179793@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=den@valinux.co.jp \
    --cc=linux-pci@vger.kernel.org \
    --cc=ntb@lists.linux.dev \
    --cc=sashiko-reviews@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