linux-kernel - Re: [RFC PATCH v3 03/35] PCI: dwc: ep: Support BAR subrange inbound mapping via address match iATU

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: <nhf3f2zaxjbzbyrmi54nytf7mqgoxjx5mk3mwaqj67d45n33tk@7hwh244msz45>
Date: Sun, 21 Dec 2025 00:36:18 +0900
From: Koichiro Den <den@...inux.co.jp>
To: Frank Li <Frank.li@....com>
Cc: dave.jiang@...el.com, ntb@...ts.linux.dev, linux-pci@...r.kernel.org, 
	dmaengine@...r.kernel.org, linux-renesas-soc@...r.kernel.org, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org, mani@...nel.org, kwilczynski@...nel.org, kishon@...nel.org, 
	bhelgaas@...gle.com, corbet@....net, geert+renesas@...der.be, magnus.damm@...il.com, 
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, vkoul@...nel.org, 
	joro@...tes.org, will@...nel.org, robin.murphy@....com, jdmason@...zu.us, 
	allenbh@...il.com, andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, Basavaraj.Natikar@....com, 
	Shyam-sundar.S-k@....com, kurt.schwemmer@...rosemi.com, logang@...tatee.com, 
	jingoohan1@...il.com, lpieralisi@...nel.org, utkarsh02t@...il.com, 
	jbrunet@...libre.com, dlemoal@...nel.org, arnd@...db.de, elfring@...rs.sourceforge.net
Subject: Re: [RFC PATCH v3 03/35] PCI: dwc: ep: Support BAR subrange inbound
 mapping via address match iATU

On Fri, Dec 19, 2025 at 09:19:26AM -0500, Frank Li wrote:
> On Thu, Dec 18, 2025 at 12:15:37AM +0900, Koichiro Den wrote:
> > Extend dw_pcie_ep_set_bar() to support Address Match Mode IB iATU
> > with the new 'submap' field in pci_epf_bar.
> >
> > The existing dw_pcie_ep_inbound_atu(), which is for BAR match mode, is
> > renamed to dw_pcie_ep_ib_atu_bar() and the new dw_pcie_ep_ib_atu_addr()
> > is introduced, which is for Address match mode.
> >
> > Signed-off-by: Koichiro Den <den@...inux.co.jp>
> > ---
> >  .../pci/controller/dwc/pcie-designware-ep.c   | 197 ++++++++++++++++--
> >  drivers/pci/controller/dwc/pcie-designware.h  |   2 +
> >  drivers/pci/endpoint/pci-epc-core.c           |   2 +-
> >  include/linux/pci-epf.h                       |  27 +++
> >  4 files changed, 215 insertions(+), 13 deletions(-)
> >
> ...
> >
> >  #define to_pci_epf_driver(drv) container_of_const((drv), struct pci_epf_driver, driver)
> >
> > +/**
> > + * struct pci_epf_bar_submap - represents a BAR subrange for inbound mapping
> > + * @phys_addr: physical address that should be mapped to the BAR subrange
> > + * @size: the size of the subrange to be mapped
> > + * @offset: The byte offset from the BAR base
> > + * @mapped: Set to true if already mapped
> > + *
> > + * When @use_submap is set in struct pci_epf_bar, an EPF driver may describe
> > + * multiple independent mappings within a single BAR. An EPC driver can use
> > + * these descriptors to set up the required address translation (e.g. multiple
> > + * inbound iATU regions) without requiring the whole BAR to be mapped at once.
> > + */
> > +struct pci_epf_bar_submap {
> > +	dma_addr_t	phys_addr;
> > +	size_t		size;
> > +	size_t		offset;
> > +	bool		mapped;
> 
> Can we move dw_pcie_ib_map's neccessary information to here, so needn't
> addition list to map it? such as atu_index.  if atu_index assign, which
> should means mapped.

The 'mapped' field in pci_epf_bar_submap is actually a leftover from an
early draft. I'll drop it, sorry for the confusion.

I would still prefer to keep the atu index in a private structure (ie.
dw_pcie_ib_map). pci_epf_bar_submap is part of the API and I think should
remain a declarative description of the requested sub-range mappings,
without exposing driver-internal state back to the caller.

> 
> > +};
> > +
> >  /**
> >   * struct pci_epf_bar - represents the BAR of EPF device
> >   * @phys_addr: physical address that should be mapped to the BAR
> > @@ -119,6 +138,9 @@ struct pci_epf_driver {
> >   *            requirement
> >   * @barno: BAR number
> >   * @flags: flags that are set for the BAR
> > + * @use_submap: set true to request subrange mappings within this BAR
> > + * @num_submap: number of entries in @submap
> > + * @submap: array of subrange descriptors allocated by the caller
> >   */
> >  struct pci_epf_bar {
> >  	dma_addr_t	phys_addr;
> > @@ -127,6 +149,11 @@ struct pci_epf_bar {
> >  	size_t		mem_size;
> >  	enum pci_barno	barno;
> >  	int		flags;
> > +
> > +	/* Optional sub-range mapping */
> > +	bool		use_submap;
> > +	int		num_submap;
> 
> Can we use num_submap != 0 means request subrange?

Some existing pci_epc_set_bar() callers seem to use a two-stage sequence,
ie. first they only initialize the BAR (with phys_addr == 0), and later
they program the actual BAR-match (re-)mapping (with phys_addr != 0).

If we used only num_submap != 0 as the discriminator, Address Match mode
initialization (num_submap == 0) would be indistinguishable from the
existing BAR-match initialization, and we could end up programming a
meaningless BAR-match mapping with phys_addr == 0. That's why I added an
explicit 'use_submap' flag in addition to 'num_submap'.

Koichiro

> 
> Frank
> > +	struct pci_epf_bar_submap	*submap;
> >  };
> >
> >  /**
> > --
> > 2.51.0
> >