On Tue, 9 Jun 2026 13:56:11 +0100, Jonathan Cameron <[email protected]> wrote:
Hi Jonathan,
> > CXL component register BAR (BAR0 on CXL Root Port and Type3 device)
> > and the CXL device register BAR (BAR2 on Type3 device) are declared
> > as 64-bit non-prefetchable memory. A standard PCIe-to-PCI bridge
> > exposes a 32-bit non-prefetchable memory window plus an (optional)
> > 64-bit prefetchable memory window, but no 64-bit non-prefetchable
> > window.
>
> When you say 'standard' do you mean that is all the PCI spec allows
> for?
Yes, I confirmed against the PCI-to-PCI Bridge Architecture
Specification, Revision 1.2 (PCI-SIG, 2003). Relevant sections:
- Section 3.2.5.8 (Memory Base Register and Memory Limit Register):
"The upper 12 bits of both the Memory Base and Memory Limit
registers are read/write and correspond to the upper 12 address
bits, AD[31::20], of 32-bit addresses."
-> The non-prefetchable memory window is 32-bit only, and the
Type 1 header defines no upper-32-bit extension for it.
- Section 3.2.5.9 (Prefetchable Memory Base/Limit Register):
The bottom 4 bits encode 64-bit support: 0h = 32-bit only,
01h = 64-bit (extended via 3.2.5.10).
- Section 3.2.5.10 (Prefetchable Base/Limit Upper 32 Bits):
Optional registers that hold AD[63::32] for the 64-bit
*prefetchable* range.
So the architecture only allows a 64-bit window when it is also
prefetchable; there is no 64-bit non-prefetchable form. PCIe
inherits this Type 1 header layout unchanged.
Public mirror of the spec text (Rev 1.1, identical wording for these
sections):
https://0x04.net/~mwk/doc/pci/PCI-to-PCI%20Bridge%20Architecture%20Specification.pdf
Official Rev 1.2 page (PCI-SIG, member access):
https://pcisig.com/specifications/conventional/pci_bridge_2_1
> > Linux therefore places 64-bit non-prefetchable BARs in the
> > 32-bit non-prefetchable bridge window, which requires the bridge to
> > own enough address space below 4 GiB.
> >
>
> This sounds a bit like the issue that Dave Jiang reported with recent
> EDK2 on x86 (fedora upgraded). We don't see it with the older EDK2
> that ships with QEMU. I haven't yet figured out exactly why.
> Arguably whatever they changed is a regression but we don't have good
> enough testing in place to have detected it early enough.
>
> I'd like some input from PCI / ACPI experts on this. +CC Michael and
> Igor.
>
> Like the previous patch we'd definitely want some testing around this
> to make sure it doesn't accidentally get broken in future.
The symptoms do look related -- in both cases UEFI's
PciHostBridgeDxe ends up not giving a 32-bit non-prefetchable
window to the CXL host bridge (ACPI0016), so build_crs() in
gpex-acpi.c returns an empty resource set. I haven't dug deep
enough into Dave's case to say whether the underlying trigger is
the same as on RISC-V virt though.
Would appreciate input from Michael / Igor / Dave on whether the
approach in this patch (carve out a dedicated cxl_mmio32 range and
emit a static _CRS for ACPI0016) is a reasonable shape for a
shared fix, or if there's a preferred direction on the PCI/ACPI
side.
Best,
Pei
