| Message ID | 20181219205640.4704-1-ard.biesheuvel@linaro.org |
|---|---|
| Headers | show |
| Series | introduce MAX_ALLOC_ADDRESS to limit boot time allocations | expand |
On Wed, 19 Dec 2018 at 21:56, Ard Biesheuvel <ard.biesheuvel@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: > - limit MAX_ALLOC_ADDRESS to 0xFFFFFFFF (4 GB) > - 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@intel.com> > Cc: Liming Gao <liming.gao@intel.com> > Cc: Jian J Wang <jian.j.wang@intel.com> > Cc: Hao Wu <hao.a.wu@intel.com> > Cc: Leif Lindholm <leif.lindholm@linaro.org> > Cc: Laszlo Ersek <lersek@redhat.com> > Cc: Eric Auger <eric.auger@redhat.com> > Cc: Andrew Jones <drjones@redhat.com> > Cc: Philippe Mathieu-Daude <philmd@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 > MAX_ALLOC_ADDRESS > Pushed as 5c8bc8be9e5e..4a1500db2b42 Thanks all _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
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: - limit MAX_ALLOC_ADDRESS to 0xFFFFFFFF (4 GB) - 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@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Auger <eric.auger@redhat.com> Cc: Andrew Jones <drjones@redhat.com> Cc: Philippe Mathieu-Daude <philmd@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 MAX_ALLOC_ADDRESS MdePkg/Include/AArch64/ProcessorBind.h | 5 ++ MdePkg/Include/Arm/ProcessorBind.h | 5 ++ MdePkg/Include/Ebc/ProcessorBind.h | 5 ++ MdePkg/Include/Ia32/ProcessorBind.h | 5 ++ MdePkg/Include/X64/ProcessorBind.h | 5 ++ .../Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 2 +- ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c | 6 +-- .../ArmVirtMemoryInitPeiLib.c | 8 +-- MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 8 +-- MdeModulePkg/Core/Dxe/Mem/Page.c | 52 +++++++++---------- 10 files changed, 63 insertions(+), 38 deletions(-) -- 2.19.2 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel