Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/41466 )
Change subject: device: Enable resource allocation above 4G boundary with allocator v4 ......................................................................
Patch Set 4:
Is there a particular reason not to move all prefmem resources above 4G?
The idea came along with the thought of resource assignment from top to bottom (stealing from the end of the last memrange): If we'd always do that, we wouldn't even need a quirk (IORESOURCE_ ABOVE_4G). We could simply default to the upper-most possible placement and then opt out by constraining the domain resource or individual resource's `.limit`.
In the PCI specification, is (PCI_BASE_ADDRESS_) MEM_PREFETCH allowed to be set without MEM_LIMIT_64 being set?
I think it's allowed for legacy PCI devices. I don't think it matters, the allocator should always adhere to the `.limit`.
My expectation is 32-bit payloads will not be able to address any DRAM or MMIO located above 4 GiB but I have not experimented or investigated this any further. I believe linear framebuffers for graphics and some DMA queues/buffers for iPXE would fail. I have not checked if AHCI/XHCI etc advertise some BARs with PREFMEM too.
I think we should handle devices by class. With an opt-out for each, e.g.
"Place all video-device resources below 4GiB" "Place all network-device resources below 4GiB"
The primary video adapter should probably not have an option and should always stay below 4G. Hmm, unless we do LinuxBoot... sigh, so many options.
This also reminded me, samsung/lumpy has PCIe NIC that incorrectly advertises MMIO register bank BAR with PREFMEM. It needs a quirk to override such that the resource hits MTRR UC window, write-combining would fail. Remotely related CB:5169.