(Symptom originally reported by Gerd Hoffmann.)

In commit 75136b29541b ("OvmfPkg/PlatformPei: reorder the 32-bit PCI
window vs. the PCIEXBAR on q35", 2019-05-16), made for bug 1814, we
raised the base of the MMCONFIG range to 0xE000_0000, and moved the
32-bit PCI MMIO aperture underneath.

This causes QEMU to generate an invalid _CRS object in the ACPI DSDT,
for \_SB.PCI0. QEMU appears to assume that the PCIEXBAR is at the lower
address, and clamps the 32-bit PCI MMIO aperture, exposed in the CRS,
above it. Partial quote from the decompiled, generated DSDT:

DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPCDSDT", 0x00000001)
{
    Scope (\_SB.PCI0)
    {
        Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
        {
            DWordMemory (ResourceProducer, PosDecode, MinFixed,
                         MaxFixed, NonCacheable, ReadWrite,
                0x00000000,         // Granularity
                0xF0000000,         // Range Minimum
                0xFEBFFFFF,         // Range Maximum
                0x00000000,         // Translation Offset
                0x0EC00000,         // Length
                ,, , AddressRangeMemory, TypeStatic)
        })
    }
}

As a consequence, the OS finds that the 32-bit MMIO BARs of all PCI
devices, originally (correctly) enumerated / assigned by the firmware,
fall outside of the _CRS. The OS (both Windows and Linux) silently
re-assign these resources. Thus, the change in behavior is mostly
invisible to users -- except when there are many (or large) 32-bit MMIO
BARs, the firmware can fit them (in the original, intended aperture),
but the OS cannot (into the small [0xF000_0000, 0xFEBF_FFFF] aperture).

QEMU is under investigation, but the fix could be intrusive and run the
risk of regressions.

A workaround in OVMF could look as follows:

- Preserve the logic added for bug 1814 in case of i440fx. i440fx is not
  affected, as it has no PCIEXBAR.

- For Q35, move the PCIEXBAR to a low address again, and move the 32-bit
  MMIO aperture above it.

- Use fixed (build-time) constants for both. Do not depend on the 32-bit
  RAM size. Making PcdPciExpressBaseAddress a dynamic PCD is intrusive
  and could cause further regressions.

- Effectively return to the pre-BZ-1814 state, except raise
  PcdPciExpressBaseAddress from 0x80000000 to a higher constant.

- We have to set PcdPciExpressBaseAddress to 0xB000_0000 as a minimum,
  as QEMU may allow 32-bit RAM to extend that high (the exclusive end
  may be at 0xB000_0000).

- However, the PcdPciExpressBaseAddress value is connected to the MTRR
  setup as well. Both the EXBAR and the 32-bit MMIO aperture should be
  marked UC.

  - If we place the EXBAR at 0xB000_0000, then we will need *two*
    variable MTRRs: one at 0xB000_0000 (size 256MB), another at
    0xC000_0000 (size 1GB). This will provide the OS with the following
    32-bit MMIO aperture: [0xC000_0000, 0xFC00_0000), i.e. 960 MB.

  - If we place the EXBAR at 0xC000_0000, then we can stick with just
    one variable MTRR: at 0xC000_0000 (size 1GB). This will provide the
    OS with the following 32-bit MMIO aperture: [0xD000_0000,
    0xFC00_0000), i.e. 704 MB.

  - Either way, the low RAM MTRR setup in the QemuInitializeRam()
    function would have to depend on the board type.