linux-kernel - Re: [PATCH 2/2] drm/xe: Move rebar to be done earlier

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: <5osrqzgrh47n6rpjulvsixwbhbh5vwxrrn6p6hpodnwisjfung@lmivgjb66oed>
Date: Mon, 29 Sep 2025 08:37:38 -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>
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>, Bjorn Helgaas <bhelgaas@...gle.com>, Simon Richter
	<Simon.Richter@...yros.de>, <linux-kernel@...r.kernel.org>,
	<stable@...r.kernel.org>
Subject: Re: [PATCH 2/2] drm/xe: Move rebar to be done earlier

Hi,

On Thu, Sep 18, 2025 at 01:58:57PM -0700, Lucas De Marchi wrote:
>There may be cases in which the BAR0 also needs to move to accommodate
>the bigger BAR2. However if it's not released, the BAR2 resize fails.
>During the vram probe it can't be released as it's already in use by
>xe_mmio for early register access.
>
>Add a new function in xe_vram and let xe_pci call it directly before
>even early device probe. This allows the BAR2 to resize in cases BAR0
>also needs to move:
>
>	[] xe 0000:03:00.0: vgaarb: deactivate vga console
>	[] xe 0000:03:00.0: [drm] Attempting to resize bar from 8192MiB -> 16384MiB
>	[] xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: releasing
>	[] xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing
>	[] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing
>	[] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x41ffffffff 64bit pref]: releasing
>	[] pcieport 0000:01:00.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
>	[] pcieport 0000:02:01.0: bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
>	[] xe 0000:03:00.0: BAR 2 [mem 0x4000000000-0x43ffffffff 64bit pref]: assigned
>	[] xe 0000:03:00.0: BAR 0 [mem 0x83000000-0x83ffffff 64bit]: assigned
>	[] pcieport 0000:00:01.0: PCI bridge to [bus 01-04]
>	[] pcieport 0000:00:01.0:   bridge window [mem 0x83000000-0x840fffff]
>	[] pcieport 0000:00:01.0:   bridge window [mem 0x4000000000-0x44007fffff 64bit pref]
>	[] pcieport 0000:01:00.0: PCI bridge to [bus 02-04]
>	[] pcieport 0000:01:00.0:   bridge window [mem 0x83000000-0x840fffff]
>	[] pcieport 0000:01:00.0:   bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]
>	[] pcieport 0000:02:01.0: PCI bridge to [bus 03]
>	[] pcieport 0000:02:01.0:   bridge window [mem 0x83000000-0x83ffffff]
>	[] pcieport 0000:02:01.0:   bridge window [mem 0x4000000000-0x43ffffffff 64bit pref]
>	[] xe 0000:03:00.0: [drm] BAR2 resized to 16384M
>	[] xe 0000:03:00.0: [drm:xe_pci_probe [xe]] BATTLEMAGE  e221:0000 dgfx:1 gfx:Xe2_HPG (20.02) ...
>
>As shown above, it happens even before we try to read any register for
>platform identification.
>
>All the rebar logic is more pci-specific than xe-specific and can be
>done very early in the probe sequence. In future it would be good to
>move it out of xe_vram.c, but this refactor is left for later.

Ilpo, can you take a look on this patch? It fixed the issue that I had
with BMG. It needs the first patch for the full fix, but the fixes are
more or less orthogonal.

thanks
Lucas De Marchi