[edk2] [PATCH v2 0/6] introduce MAX_ALLOC_ADDRESS to limit boot time allocations

Ard Biesheuvel ard.biesheuvel at linaro.org
Thu Dec 20 02:38:32 PST 2018

On Wed, 19 Dec 2018 at 21:56, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> Since modifying MAX_ADDRESS to limit the memory used at boot time has
> turned out to be intractible, this series proposes another approach to do
> the same, by introducing MAX_ALLOC_ADDRESS for firmware internal use.
> I tested these patches with ArmVirtQemu in the following way:
> - build QEMU_EFI.fd
> - run it under mach-virt with 4 GB of DRAM and highmem=off
> This runs as expected, and produces a memory map ending in the following
> lines
> BS_Data    00000000FFFFD000-00000000FFFFFFFF 0000000000000003 0000000000000008
> Available  0000000100000000-000000013FFFFFFF 0000000000040000 0000000000000008
> which proves that the memory above the limit is recorded and reported by
> the OS, but left untouched by the firmware memory allocation routines.
> Cc: Michael D Kinney <michael.d.kinney at intel.com>
> Cc: Liming Gao <liming.gao at intel.com>
> Cc: Jian J Wang <jian.j.wang at intel.com>
> Cc: Hao Wu <hao.a.wu at intel.com>
> Cc: Leif Lindholm <leif.lindholm at linaro.org>
> Cc: Laszlo Ersek <lersek at redhat.com>
> Cc: Eric Auger <eric.auger at redhat.com>
> Cc: Andrew Jones <drjones at redhat.com>
> Cc: Philippe Mathieu-Daude <philmd at redhat.com>
> Ard Biesheuvel (6):
>   MdePkg/Base: introduce MAX_ALLOC_ADDRESS
>   MdeModulePkg/Dxe/Gcd: disregard memory above MAX_ALLOC_ADDRESS
>   MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account
>   ArmPkg/ArmMmuLib: take MAX_ALLOC_ADDRESS into account
>   ArmPlatformPkg/MemoryInitPeim: take MAX_ALLOC_ADDRESS into account
>   ArmVirtPkg/MemoryInitPeiLib: split memory HOB based on

Pushed as  5c8bc8be9e5e..4a1500db2b42

Thanks all

More information about the edk2-devel mailing list