Hi,

On 10/22/25 1:20 AM, Ilpo Järvinen wrote:

Could you please test if the patch below helps.

Yes, this looks better.

  - "good" is the 6.17 reference
  - "shrink" is with this patch and the BAR0 release from Lucas
  - "bar0" is with this patch, with the bridge BAR0 still mapped (i.e. 
without the patch from Lucas)

If you compare "good" vs "bar0", the differences are now fairly minimal. 
The non-prefetchable window has shrunk, but assignments are otherwise 
the same.

I've added "lspci -v" output as well, which shows the bridge 
configuration. I'm still not sure that the address mappings between PCI 
and system bus are 1:1.

So the BAR0 release patch from Lucas seems to be no longer required with 
this, although it does align the prefetchable area better, so in theory 
it would allow a 512G BAR to be mapped. In practice, there are no Intel 
dGPUs with 512G VRAM.

There's indeed something messy and odd going on here with the resource and
window mappings, in the bad case there's also this line which doesn't make
much sense:
+pci 0030:01:00.0: bridge window [mem 0x6200000000000-0x6203fbff0ffff 64bit pref]: can't claim; address conflict with 0030:01:00.0 [mem 0x6200020000000-0x62000207fffff 64bit pref]

...but that conflicting resource was not assigned in between releasing
this bridge window and trying to claim it back so how did that
conflicting resource get there is totally mysterious to me. It doesn't
seem related directly to the the resize no longer working though.

That is the upstream bridge's BAR0 mapping, which is not a bridge 
window, so presumably the window allocation algorithm is unaware of it.

quoted

It's a bit weird that there is a log message that says "enabling device", then
the BARs are reconfigured. I'd want the decoding logic to be inactive while
addresses are assigned.

So no real issue here and only logging is not the way you'd want it?

It works for the GPU, but I'm unsure about my FPGA designs now, for the 
most part, I would have expected that the "enable memory decoding" bit 
had to be 0 while BAR registers are being written, and I would have 
expected the driver to resize the BAR first, then enable the device.

    Simon