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: <n7syfqiqbtoqmb4zpxuec44vpnwfgbzfhuviknjibbf7dezmpk@joeksfvzd3hw>
Date: Thu, 2 Oct 2025 11:09:35 -0500
From: Lucas De Marchi <lucas.demarchi@...el.com>
To: <intel-xe@...ts.freedesktop.org>, <linux-pci@...r.kernel.org>,
	<dri-devel@...ts.freedesktop.org>, Bjorn Helgaas <bhelgaas@...gle.com>
CC: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, "Icenowy
 Zheng" <uwu@...nowy.me>, Vivian Wang <wangruikang@...as.ac.cn>, Thomas
 Hellström <thomas.hellstrom@...ux.intel.com>, Rodrigo Vivi
	<rodrigo.vivi@...el.com>, Simon Richter <Simon.Richter@...yros.de>,
	<linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>
Subject: Re: [PATCH 1/2] PCI: Release BAR0 of an integrated bridge to allow
 GPU BAR resize

On Thu, Sep 18, 2025 at 01:58:56PM -0700, Lucas De Marchi wrote:
>From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
>
>Resizing BAR to a larger size has to release upstream bridge windows in
>order make the bridge windows larger as well (and to potential relocate
>them into a larger free block within iomem space). Some GPUs have an
>integrated PCI switch that has BAR0. The resource allocation assigns
>space for that BAR0 as it does for any resource.
>
>An extra resource on a bridge will pin its upstream bridge window in
>place which prevents BAR resize for anything beneath that bridge.
>
>Nothing in the pcieport driver provided by PCI core, which typically is
>the driver bound to these bridges, requires that BAR0. Because of that,
>releasing the extra BAR does not seem to have notable downsides but
>comes with a clear upside.
>
>Therefore, release BAR0 of such switches using a quirk and clear its
>flags to prevent any new invocation of the resource assignment
>algorithm from assigning the resource again.
>
>Due to other siblings within the PCI hierarchy of all the devices
>integrated into the GPU, some other devices may still have to be
>manually removed before the resize is free of any bridge window pins.
>Such siblings can be released through sysfs to unpin windows while
>leaving access to GPU's sysfs entries required for initiating the
>resize operation, whereas removing the topmost bridge this quirk
>targets would result in removing the GPU device as well so no manual
>workaround for this problem exists.
>
>Reported-by: Lucas De Marchi <lucas.demarchi@...el.com>
>Link: https://lore.kernel.org/linux-pci/fl6tx5ztvttg7txmz2ps7oyd745wg3lwcp3h7esmvnyg26n44y@owo2ojiu2mov/
>Link: https://lore.kernel.org/intel-xe/20250721173057.867829-1-uwu@icenowy.me/
>Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
>Cc: <stable@...r.kernel.org> # v6.12+
>Signed-off-by: Lucas De Marchi <lucas.demarchi@...el.com>
>---
>
>Remarks from Ilpo: this feels quite hacky to me and I'm working towards a
>better solution which is to consider Resizable BAR maximum size the
>resource fitting algorithm. But then, I don't expect the better solution
>to be something we want to push into stable due to extremely invasive
>dependencies. So maybe consider this an interim/legacy solution to the
>resizing problem and remove it once the algorithmic approach works (or
>more precisely retain it only in the old kernel versions).

Bjorn, would that be acceptable? If so, please let me know if I can take
it through the drm tree together with the second patch to have this BAR
resize fixed for BMG.

thanks
Lucas De Marchi


>---
> drivers/pci/quirks.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
>diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>index d97335a401930..9b1c08de3aa89 100644
>--- a/drivers/pci/quirks.c
>+++ b/drivers/pci/quirks.c
>@@ -6338,3 +6338,26 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
> #endif
>+
>+/*
>+ * PCI switches integrated into Intel Arc GPUs have BAR0 that prevents
>+ * resizing the BARs of the GPU device due to that bridge BAR0 pinning the
>+ * bridge window it's under in place. Nothing in pcieport requires that
>+ * BAR0.
>+ *
>+ * Release and disable BAR0 permanently by clearing its flags to prevent
>+ * anything from assigning it again.
>+ */
>+static void pci_release_bar0(struct pci_dev *pdev)
>+{
>+	struct resource *res = pci_resource_n(pdev, 0);
>+
>+	if (!res->parent)
>+		return;
>+
>+	pci_release_resource(pdev, 0);
>+	res->flags = 0;
>+}
>+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_INTEL, 0x4fa0, pci_release_bar0);
>+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_INTEL, 0x4fa1, pci_release_bar0);
>+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_INTEL, 0xe2ff, pci_release_bar0);
>
>-- 
>2.50.1
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ