linux-kernel - [PATCH 0/2] drm/xe: Fix some rebar issues

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

Message-ID: <20250918-xe-pci-rebar-2-v1-0-6c094702a074@intel.com>
Date: Thu, 18 Sep 2025 13:58:55 -0700
From: Lucas De Marchi <lucas.demarchi@...el.com>
To: intel-xe@...ts.freedesktop.org,
	linux-pci@...r.kernel.org,
	dri-devel@...ts.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@...el.com>,
	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>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Simon Richter <Simon.Richter@...yros.de>,
	linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: [PATCH 0/2] drm/xe: Fix some rebar issues

Our implementation for BAR2 (lmembar) resize works at the xe_vram layer
and only releases that BAR before resizing. That is not always
sufficient. If the parent bridge needs to move, the BAR0 also needs to
be released, otherwise the resize fails. This is the case of not having
enough space allocated from the beginning.

Also, there's a BAR0 in the upstream port of the pcie switch in BMG
preventing the resize to propagate to the bridge as previously discussed
in https://lore.kernel.org/intel-xe/20250721173057.867829-1-uwu@icenowy.me/
and https://lore.kernel.org/intel-xe/wqukxnxni2dbpdhri3cbvlrzsefgdanesgskzmxi5sauvsirsl@xor663jw2cdw
I'm bringing that commit from Ilpo here so this can be tested with the
xe changes and propagate to stable. Note that the use of a pci fixup is
not ideal, but without intrusive changes on resource fitting it's
possibly the best alternative. I also have confirmation from HW folks
that the BAR in the upstream port has no production use.

I have more cleanups on top on the xe side, but those conflict with some
refactors Ilpo is working on as prep for the resource fitting, so I will
wait things settle to submit again.

I propose to take this through the drm tree.

With this I could resize the lmembar on some problematic hosts and after
doing an SBR, with one caveat: the audio device also prevents the BAR
from moving and it needs to be manually removed before resizing. With
the PCI refactors and BAR fitting logic that Ilpo is working on, it's
expected that it won't be needed for a long time.

Signed-off-by: Lucas De Marchi <lucas.demarchi@...el.com>
---
Ilpo Järvinen (1):
      PCI: Release BAR0 of an integrated bridge to allow GPU BAR resize

Lucas De Marchi (1):
      drm/xe: Move rebar to be done earlier

 drivers/gpu/drm/xe/xe_pci.c  |  2 ++
 drivers/gpu/drm/xe/xe_vram.c | 34 ++++++++++++++++++++++++++--------
 drivers/gpu/drm/xe/xe_vram.h |  1 +
 drivers/pci/quirks.c         | 23 +++++++++++++++++++++++
 4 files changed, 52 insertions(+), 8 deletions(-)

base-commit: 8031d70dbb4201841897de480cec1f9750d4a5dc
change-id: 20250917-xe-pci-rebar-2-c0fe2f04c879

Lucas De Marchi