ArmVirtualizationPkg/PciHostBridgeDxe: get MMIO BARs from our own aperture

This is our MMIO space map:

> GCD:AddMemorySpace(Base=0000000010000000,Length=000000002EFF0000)
>   GcdMemoryType   = MMIO
>   Capabilities    = 0000000000000001
>   Status = Success
> GCDMemType Range                             Capabilities     Attributes
> ========== ================================= ================ ================
> NonExist   0000000000000000-0000000003FFFFFF 0000000000000000 0000000000000000
> MMIO       0000000004000000-0000000007FFFFFF C000000000000001 8000000000000001

NorFlashDxe adds this, but does not allocate it.

> NonExist   0000000008000000-000000000900FFFF 0000000000000000 0000000000000000
> MMIO       0000000009010000-0000000009010FFF C000000000000001 8000000000000001

Added by RealTimeClockRuntimeDxe, but also not allocated.

> NonExist   0000000009011000-000000000FFFFFFF 0000000000000000 0000000000000000
> MMIO       0000000010000000-000000003EFEFFFF C000000000000001 0000000000000000

Added by ourselves.

> NonExist   000000003EFF0000-000000003FFFFFFF 0000000000000000 0000000000000000
> SystemMem  0000000040000000-00000000BFFFFFFF 800000000000000F 0000000000000008*
> NonExist   00000000C0000000-0000FFFFFFFFFFFF 0000000000000000 0000000000000000

In the EfiPciHostBridgeAllocateResources phase, we allocate memory BARs
bottom up, from whichever MMIO range comes first and has room left.
Unfortunately, this places memory BARs into MMIO ranges that belong to
other devices. (Arguably, their respective drivers should not just add,
but immediately allocate those ranges as well.)

(

  This problem is not seen in OVMF / PcAtChipsetPkg, because there we
  allocate bottom-up from the range

    [max(2GB, top-of-low-RAM), 0xFC000000).

  (See the MMIO resource descriptor HOB created in MemMapInitialization()
  [OvmfPkg/PlatformPei/Platform.c].)

  That MMIO range fits in the static [2GB, 4GB) aperture given in
  "mResAperture" in PcAtChipsetPkg/PciHostBridgeDxe; plus other MMIO
  ranges (IO-APIC, HPET, LAPIC, flash chip) are higher than 0xFC000000.
  Hence the bottom-up BAR allocation in OvmfPkg always finds the right
  MMIO range first.

)

In ArmVirtualizationPkg/PciHostBridgeDxe we can solve the problem by
working our way downwards from the top of our own aperture.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16906 6f19259b-4bc3-4df7-8a09-765794883524

diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c b/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
index 78c12d0009bf44044b3e5fa1888080441cebad49..1534c3dc04c2be05ed3c6dcde2c2b723237bac81 100644 (file)
--- a/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
@@ -423,8 +423,9 @@ NotifyPhase(
                   BitsOfAlignment = 0;\r
                 }\r
                   \r
+                BaseAddress = mResAperture[0][0].MemLimit;\r
                 Status = gDS->AllocateMemorySpace (\r
-                                EfiGcdAllocateAnySearchBottomUp, \r
+                                EfiGcdAllocateMaxAddressSearchTopDown,\r
                                 EfiGcdMemoryTypeMemoryMappedIo, \r
                                 BitsOfAlignment,\r
                                 AddrLen,\r