Re: [PATCH 3/4] hw/riscv/virt, gpex: Provide 32-bit MMIO window for CXL host bridges

[Chen Pei <cp0613@linux.alibaba.com>]

On Tue, 9 Jun 2026 13:56:11 +0100, Jonathan Cameron <jic23@kernel.org> 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