Re: [PATCH v5 00/14] PCI: Resource placement algorithm fixes

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]

On Fri, 6 Nov 2026, Nikolas Joshua Britton wrote:

> On Fri, 6 Nov 2026, Ilpo Järvinen wrote:
> > There have been major changes so any retesting is appreciated (the
> > 4 candidates patch is largely the same so I kept the Tested-by tags but
> > everything around has been changing so even that is on the borderline
> > when it comes to the validity of the existing tags).
> 
> I retested v5 on the Mac Pro 7,1 from my report (two Vega II Duo cards,
> four Vega 20 dies behind two root ports, BAR0 resized to 32G on every
> die).
> 
> v7.3 and later don't boot on this machine for reasons unrelated to this
> series, so I tested on v7.2.15 plus 5012a6953208 ("PCI: Do not add
> hotplug reservation multiple times"), which 11/14 and 12/14 depend on.
> All 14 patches then apply as posted, and drivers/pci/setup-bus.c and
> drivers/pci/setup-res.c come out byte-identical to v7.4-rc1 + v5.
> 
> Every BAR is assigned, both root port windows are 96G, and all four dies
> get their 32G BAR0. The first root port:
> 
>   pci 0000:06:00.0: bridge window [mem 0x9e800000000-0x9ffffffffff 64bit pref]: assigned
>   pci 0000:07:00.0: bridge window [mem 0x9e800000000-0x9ffffffffff 64bit pref]: assigned
>   pci 0000:08:08.0: bridge window [mem 0x9f7ffe00000-0x9ffffffffff 64bit pref]: assigned
>   pci 0000:08:10.0: bridge window [mem 0x9e800000000-0x9f0001fffff 64bit pref]: assigned
>   pci 0000:0b:00.0: BAR 0 [mem 0x9f800000000-0x9ffffffffff 64bit pref]: assigned
>   pci 0000:0b:00.0: BAR 2 [mem 0x9f7ffe00000-0x9f7ffffffff 64bit pref]: assigned
>   pci 0000:0e:00.0: BAR 0 [mem 0x9e800000000-0x9efffffffff 64bit pref]: assigned
>   pci 0000:0e:00.0: BAR 2 [mem 0x9f000000000-0x9f0001fffff 64bit pref]: assigned
> 
> The second root port (14:00.0) has the same layout at 0xbe800000000.
> 
> Compared with v4, the two die chains swapped ends of the window: 08:08.0
> and the windows nested below it (09:00.0, 0a:00.0) now sit at the top,
> with the 2M BAR2 at their left edge. That is the case the dropped
> nested-window fix covered, and it still assigns without that patch.
> amdgpu binds all four dies and compute across them works.

Also the candidate selection precedence change impacts ordering. TBH, I 
liked the v4 order better because it really tried to preserve the left 
edge for large blocks better but there were just so many corner cases with 
it so v5 now uses the largest contiguous size before the largest natural 
size. I might revisit this at some point but getting these regressions 
addressed in mainline is more important than perfection and my 
preferences.

> Tested-by: Nikolas Joshua Britton <nbritton@exabit.io>

Thanks for testing.

All looks promising, sashiko came up nothing interesting. It took 
quite long to get to that point but I think the overall feel I've the 
series feels much more polished now than what v4 was.

-- 
 i.