Hi,

On 10/17/25 00:45, Ilpo Järvinen wrote:

Is this stock 6.18-rc1?

This is drm-tip, plus a few extras that actually allow me to load the 
GPU driver, but no PCIe changes.

Was this resize attempted automatically by the xe driver during boot, not
triggered manually through sysfs, right? (Inferring that's likely the case
given the proximity of the "enabling device" message.)

Yes, that's the xe driver doing that.

I need to know PCI resource allocations of the parents too. Preferrably
dmesg and /proc/iomem from both working and broken cases so it's easier
to find the differences.

I've attached those.

  - dmesg.good/iomem.good: taken with 6.17 (drm-tip from last week)
  - dmesg.bad/iomem.bad: taken with 6.18rc1 (drm-tip after update)
  - dmesg.meh/iomem.meh: with the rebar patch 1/2 from Lucas. 2/2 is 
already merged. The GPU works at least, but has a 256MB aperture
  - dmesg.rev/iomem.rev: with 85796d20a690 and 3ab10f83e277 reverted

I'd very much want to do this too but I've higher priority items on my
list, one of which attempts to resolve these resizable BARs using other
way, that is, size the bridge windows considering the maximum size of the
BAR right from the start. That would remove the need to try to enlarge
BARs afterwards as there won't be more room for them anyway.

The bridge windows are set up by firmware, but they should be large 
enough on POWER, given that each slot gets its own domain, and 
controllers are allocated 256G each.

I also dimly remember these are be configured so that the first 2G of 
address space are on the PCIe bus, and the first 2G of memory are 
addressed at a higher address and only accessible to 64 bit capable 
cards, so 32 bit cards can still access 2 GB of PCIe memory for P2PDMA 
and 2 GB of RAM (so the root complex performs address translation).

The result of this seems to be that smaller BARs end up in the 2 GB 
window, so only the VRAM aperture is inside the larger 64-bit-only 
window, so the window containing the bridge's BAR0 does not need to be 
changed.

quoted

Also, why do we change the BAR assignment while mem decoding is active?

pci_resize_resource() does check for
pci_resize_is_memory_decoding_enabled(), do you think that is not enough?

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.

    Simon