linux-kernel - Re: [PATCH 0/2] PCI: endpoint: BAR subrange mapping support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aVzS3_Vx8hXZte1Z@fedora>
Date: Tue, 6 Jan 2026 10:16:15 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Koichiro Den <den@...inux.co.jp>
Cc: jingoohan1@...il.com, mani@...nel.org, lpieralisi@...nel.org,
	kwilczynski@...nel.org, robh@...nel.org, bhelgaas@...gle.com,
	Frank.Li@....com, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] PCI: endpoint: BAR subrange mapping support

On Tue, Jan 06, 2026 at 12:09:24PM +0900, Koichiro Den wrote:
> On Tue, Jan 06, 2026 at 10:52:54AM +0900, Koichiro Den wrote:
> > On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote:
> > > Hello Koichiro,
> > > 
> > > On Mon, Jan 05, 2026 at 05:02:12PM +0900, Koichiro Den wrote:
> > > > This series proposes support for mapping subranges within a PCIe endpoint
> > > > BAR and enables controllers to program inbound address translation for
> > > > those subranges.
> > > > 
> > > > The first patch introduces generic BAR subrange mapping support in the
> > > > PCI endpoint core. The second patch adds an implementation for the
> > > > DesignWare PCIe endpoint controller using Address Match Mode IB iATU.
> > > > 
> > > > This series is a spin-off from a larger RFC series posted earlier:
> > > > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> > > > 
> > > > Base:
> > > >   git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> > > >   branch: controller/dwc
> > > >   commit: 68ac85fb42cf ("PCI: dwc: Use cfg0_base as iMSI-RX target address
> > > >                          to support 32-bit MSI devices")
> > > > 
> > > > Thank you for reviewing,
> > > > 
> > > > Koichiro Den (2):
> > > >   PCI: endpoint: Add BAR subrange mapping support
> > > >   PCI: dwc: ep: Support BAR subrange inbound mapping via address-match
> > > >     iATU
> > > 
> > > I have nothing against this feature, but the big question here is:
> > > where is the user?
> > > 
> > > Usually, we don't add a new feature without having a single user of said
> > > feature.
> > > 
> > 
> > The first user will likely be Remote eDMA-backed NTB transport. An RFC
> > series,
> > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> > referenced in the cover letter relies on Address Match Mode support.
> > In that sense, this split series is prerequisite work, and if this gets
> > acked, I will post another patch series that utilizes this in the NTB code.
> > 
> > At least for Renesas R-Car S4, where 64-bit BAR0/BAR2 and 32-bit BAR4 are
> > available, exposing the eDMA regsister and LL regions to the host requires
> > at least two mappings (one for register and another for a contiguous LL
> > memory). Address Match Mode allows a flexible and extensible layout for the
> > required regions.
> > 
> > > 
> > > One thing that I would like to see though:
> > > stricter verification of the pci_epf_bar_submap array.
> > > 
> > > For DWC, we know that the minimum size that an iATU can map is stored in:
> > > (struct dw_pcie *pci) pci->region_align.
> > > 
> > > Thus, each element in the pci_epf_bar_submap array has to have a size that
> > > is a multiple of pci->region_align.
> > > 
> > > I don't see that you ever verify this anywhere.
> > 
> > I missed it, will add the check.
> 
> My reply above was wrong, the region_align-related validation is already
> handled in dw_pcie_prog_inbound_atu(). I don't think we need to duplicate
> the same check at (A) (see below) in dw_pcie_ep_ib_atu_addr(), and would
> prefer to keep the code simple as possible since this is not a fast path.

The region align check in dw_pcie_prog_inbound_atu() validates that the
addresses (pci_addr and parent_bus_addr) are aligned to region_align
(min iATU size).

You also need to check that the size of the region mapped is aligned to
region_align (min iATU size).


Kind regards,
Niklas