Re: [RFC PATCH] PCI: Tolerate non-prefetchable 64-bit BARs in prefetchable windows

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3919 bytes --]

On Thu, 10 Sep 2026, Ard Biesheuvel wrote:

> From: Ard Biesheuvel <ardb@kernel.org>
> 
> The prefetchable vs. non-prefetchable distinction is a relic of
> conventional PCI, to denote from which regions PCI-PCI bridges were
> permitted to perform speculative readahead.
> 
> For software compatibility reasons, PCI Express inherited the Type 1
> header and models PCIe root ports as PCI-PCI bridges. However, this
> readahead behavior does not exist in PCIe, and so this distinction has
> mostly become meaningless on the bridge level.
> 
> As per the PCIe r6.3 ECN "Removing Prefetchable Terminology", the
> 'prefetchable' designation has been removed from the specification
> entirely, on the basis that it is obsolete, and is being abused to
> inform memory mapping attributes and other device/BAR level properties
> that it was never intended for.
> 
> Given the limited range for non-prefetchable windows in the Type 1
> header, and the fact that the distinction no longer exists for PCIe,
> resource allocation performed by firmware may result in non-prefetchable
> 64-bit BARs being allocated inside prefetchable bridge windows.
> 
> Linux rejects such allocations ("can't claim; no compatible bridge
> window") when it encounters them, but will usually fail to produce an
> alternative allocation, given that firmware wouldn't have placed them
> there in the first place if there was sufficient space in the
> non-prefetchable window.
> 
> So at the very least, let's not reject such allocations when they were
> made by the firmware.
> 
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> Link: https://github.com/tianocore/edk2/issues/13104
> 
>  drivers/pci/pci.c   | 3 ++-
>  include/linux/pci.h | 4 ++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f8..e33eb9f3a139 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -761,7 +761,8 @@ struct resource *pci_find_parent_resource(const struct pci_dev *dev,
>  			 * not, the allocator made a mistake.
>  			 */
>  			if (r->flags & IORESOURCE_PREFETCH &&
> -			    !(res->flags & IORESOURCE_PREFETCH))
> +			    !(res->flags & IORESOURCE_PREFETCH) &&
> +			    !pci_is_pcie(dev))
>  				return NULL;
>  
>  			/*

I was more thinking along the lines of always setting IORESOURCE_PREFETCH 
for 64-bit BARs on PCIe devices but I've not had time to look at that/test 
how many things would break as a result. ...It would seem much simpler 
solution to differentiate PCI from PCIe while keeping the existing logic 
without adding similar pci_is_pcie() checks everywhere.

> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index d31a8d107b1e..1cbb4b6c02c3 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2684,7 +2684,7 @@ static inline void pci_vf_drivers_autoprobe(struct pci_dev *dev, bool probe) { }
>   * need to calculate PCIe capability offset from raw device for some
>   * reasons, please use pci_find_capability() instead.
>   */
> -static inline int pci_pcie_cap(struct pci_dev *dev)
> +static inline int pci_pcie_cap(const struct pci_dev *dev)
>  {
>  	return dev->pcie_cap;
>  }
> @@ -2695,7 +2695,7 @@ static inline int pci_pcie_cap(struct pci_dev *dev)
>   *
>   * Returns: true if the PCI device is PCI Express capable, false otherwise.
>   */
> -static inline bool pci_is_pcie(struct pci_dev *dev)
> +static inline bool pci_is_pcie(const struct pci_dev *dev)
>  {
>  	return pci_pcie_cap(dev);
>  }
> 

This const conversion should be done in a separate preparatory patch (if 
needed in the end, though IMO it wouldn't hurt to have it as const 
anyway even if it's not necessary for the 64-bit/pref change in the end).

-- 
 i.