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] [day] [month] [year] [list]

Message-ID: <6dbjjx3q543e3nllxhl66aczujifikf6g2hp4kjjg6ojoz4r47@z5uvbjqlrxnb>
Date: Tue, 6 Jan 2026 21:39:14 +0900
From: Koichiro Den <den@...inux.co.jp>
To: Niklas Cassel <cassel@...nel.org>
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 10:16:15AM +0100, Niklas Cassel wrote:
> 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).

You're right, thanks for pointing that out.

Koichiro

> 
> 
> Kind regards,
> Niklas