[edk2,RFC,3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account

Message ID 20181207112304.19765-4-ard.biesheuvel@linaro.org
State Superseded
Headers show
Series
  • introduce MAX_ALLOC_ADDRESS to limit boot time allocations
Related show

Commit Message

Ard Biesheuvel Dec. 7, 2018, 11:23 a.m.
Take MAX_ALLOC_ADDRESS into account in the implementation of the
page allocation routines, so that they will only return memory
that is addressable by the CPU at boot time, even if more memory
is available in the GCD memory map.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

---
 MdeModulePkg/Core/Dxe/Mem/Page.c | 52 ++++++++++----------
 1 file changed, 26 insertions(+), 26 deletions(-)

-- 
2.19.2

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Comments

Wang, Jian J Dec. 10, 2018, 2:04 a.m. | #1
Hi Ard,

I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough
test for them (IA32/X64 for my concern).

In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS
in MemoryAllocationLib like following situation?

(MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c)
VOID *
InternalAllocateCopyPool (
  IN EFI_MEMORY_TYPE  PoolType,
  IN UINTN            AllocationSize,
  IN CONST VOID       *Buffer
  )
{
  VOID  *Memory;

  ASSERT (Buffer != NULL);
  ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1));
  ...
}

Regards,
Jian


> -----Original Message-----

> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]

> Sent: Friday, December 07, 2018 7:23 PM

> To: edk2-devel@lists.01.org

> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Kinney, Michael D

> <michael.d.kinney@intel.com>; Gao, Liming <liming.gao@intel.com>; Wang,

> Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif

> Lindholm <leif.lindholm@linaro.org>; Laszlo Ersek <lersek@redhat.com>; Eric

> Auger <eric.auger@redhat.com>; Andrew Jones <drjones@redhat.com>;

> Philippe Mathieu-Daude <philmd@redhat.com>

> Subject: [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take

> MAX_ALLOC_ADDRESS into account

> 

> Take MAX_ALLOC_ADDRESS into account in the implementation of the

> page allocation routines, so that they will only return memory

> that is addressable by the CPU at boot time, even if more memory

> is available in the GCD memory map.

> 

> Contributed-under: TianoCore Contribution Agreement 1.1

> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---

>  MdeModulePkg/Core/Dxe/Mem/Page.c | 52 ++++++++++----------

>  1 file changed, 26 insertions(+), 26 deletions(-)

> 

> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c

> b/MdeModulePkg/Core/Dxe/Mem/Page.c

> index 961c5b833546..5ad8e1171ef7 100644

> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c

> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c

> @@ -52,26 +52,26 @@ LIST_ENTRY   mFreeMemoryMapEntryList =

> INITIALIZE_LIST_HEAD_VARIABLE (mFreeMemor

>  BOOLEAN      mMemoryTypeInformationInitialized = FALSE;

> 

>  EFI_MEMORY_TYPE_STATISTICS mMemoryTypeStatistics[EfiMaxMemoryType +

> 1] = {

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  //

> EfiReservedMemoryType

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiLoaderCode

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiLoaderData

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiBootServicesCode

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiBootServicesData

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  //

> EfiRuntimeServicesCode

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  //

> EfiRuntimeServicesData

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiConventionalMemory

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiUnusableMemory

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  //

> EfiACPIReclaimMemory

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  //

> EfiACPIMemoryNVS

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiMemoryMappedIO

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiMemoryMappedIOPortSpace

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  // EfiPalCode

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiPersistentMemory

> -  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }   //

> EfiMaxMemoryType

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  //

> EfiReservedMemoryType

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiLoaderCode

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiLoaderData

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiBootServicesCode

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiBootServicesData

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  //

> EfiRuntimeServicesCode

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  //

> EfiRuntimeServicesData

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiConventionalMemory

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiUnusableMemory

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  //

> EfiACPIReclaimMemory

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  //

> EfiACPIMemoryNVS

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiMemoryMappedIO

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiMemoryMappedIOPortSpace

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  //

> EfiPalCode

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  //

> EfiPersistentMemory

> +  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }   //

> EfiMaxMemoryType

>  };

> 

> -EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ADDRESS;

> -EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ADDRESS;

> +EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ALLOC_ADDRESS;

> +EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ALLOC_ADDRESS;

> 

>  EFI_MEMORY_TYPE_INFORMATION

> gMemoryTypeInformation[EfiMaxMemoryType + 1] = {

>    { EfiReservedMemoryType,      0 },

> @@ -419,7 +419,7 @@ PromoteMemoryResource (

>      Entry = CR (Link, EFI_GCD_MAP_ENTRY, Link, EFI_GCD_MAP_SIGNATURE);

> 

>      if (Entry->GcdMemoryType == EfiGcdMemoryTypeReserved &&

> -        Entry->EndAddress < MAX_ADDRESS &&

> +        Entry->EndAddress < MAX_ALLOC_ADDRESS &&

>          (Entry->Capabilities & (EFI_MEMORY_PRESENT |

> EFI_MEMORY_INITIALIZED | EFI_MEMORY_TESTED)) ==

>            (EFI_MEMORY_PRESENT | EFI_MEMORY_INITIALIZED)) {

>        //

> @@ -640,7 +640,7 @@ CoreAddMemoryDescriptor (

>                gMemoryTypeInformation[FreeIndex].NumberOfPages

>                );

>              mMemoryTypeStatistics[Type].BaseAddress    = 0;

> -            mMemoryTypeStatistics[Type].MaximumAddress = MAX_ADDRESS;

> +            mMemoryTypeStatistics[Type].MaximumAddress =

> MAX_ALLOC_ADDRESS;

>            }

>          }

>          return;

> @@ -697,7 +697,7 @@ CoreAddMemoryDescriptor (

>        }

>      }

>      mMemoryTypeStatistics[Type].CurrentNumberOfPages = 0;

> -    if (mMemoryTypeStatistics[Type].MaximumAddress == MAX_ADDRESS) {

> +    if (mMemoryTypeStatistics[Type].MaximumAddress ==

> MAX_ALLOC_ADDRESS) {

>        mMemoryTypeStatistics[Type].MaximumAddress =

> mDefaultMaximumAddress;

>      }

>    }

> @@ -1318,15 +1318,15 @@ CoreInternalAllocatePages (

>    //

>    // The max address is the max natively addressable address for the processor

>    //

> -  MaxAddress = MAX_ADDRESS;

> +  MaxAddress = MAX_ALLOC_ADDRESS;

> 

>    //

>    // Check for Type AllocateAddress,

>    // if NumberOfPages is 0 or

> -  // if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ADDRESS or

> +  // if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ALLOC_ADDRESS or

>    // if (Start + NumberOfBytes) rolls over 0 or

> -  // if Start is above MAX_ADDRESS or

> -  // if End is above MAX_ADDRESS,

> +  // if Start is above MAX_ALLOC_ADDRESS or

> +  // if End is above MAX_ALLOC_ADDRESS,

>    // return EFI_NOT_FOUND.

>    //

>    if (Type == AllocateAddress) {

> @@ -1968,7 +1968,7 @@ CoreAllocatePoolPages (

>    //

>    // Find the pages to convert

>    //

> -  Start = FindFreePages (MAX_ADDRESS, NumberOfPages, PoolType, Alignment,

> +  Start = FindFreePages (MAX_ALLOC_ADDRESS, NumberOfPages, PoolType,

> Alignment,

>                           NeedGuard);

> 

>    //

> --

> 2.19.2


_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Ard Biesheuvel Dec. 10, 2018, 7:22 a.m. | #2
On Mon, 10 Dec 2018 at 03:04, Wang, Jian J <jian.j.wang@intel.com> wrote:
>

> Hi Ard,

>

> I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough

> test for them (IA32/X64 for my concern).

>


For all other architectures, MAX_ADDRESS == MAX_ALLOC_ADDRESS is
always true, so these changes only affect AARCH64.

> In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS

> in MemoryAllocationLib like following situation?

>

> (MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c)

> VOID *

> InternalAllocateCopyPool (

>   IN EFI_MEMORY_TYPE  PoolType,

>   IN UINTN            AllocationSize,

>   IN CONST VOID       *Buffer

>   )

> {

>   VOID  *Memory;

>

>   ASSERT (Buffer != NULL);

>   ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1));

>   ...


This assert ensures that the copied buffer does not extend across the
end of the address space and wraps. This is a separate concern, and is
similar to numerous other occurrences of MAX_ADDRESS that maybe we
should update as well at some point. However, it does not affect page
allocation at all, it only puts an upper bound on the *size* of the
allocation. So the changes as they are will be sufficient to ensure
that AllocateCopyPool() does not allocate from a region that is not
addressable by the CPU.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Gao, Liming Dec. 10, 2018, 2:52 p.m. | #3
Ard:
  I prefer to define MAX_ALLOC_ADDRESS together with MAX_ADDRESS in ProcessorBind.h. I don't want to leave the choice to override MAX_ALLOC_ADDRESS definition. 

Thanks
Liming
> -----Original Message-----

> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel

> Sent: Monday, December 10, 2018 3:23 PM

> To: Wang, Jian J <jian.j.wang@intel.com>

> Cc: Andrew Jones <drjones@redhat.com>; Wu, Hao A <hao.a.wu@intel.com>; edk2-devel@lists.01.org; Gao, Liming

> <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>

> Subject: Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account

> 

> On Mon, 10 Dec 2018 at 03:04, Wang, Jian J <jian.j.wang@intel.com> wrote:

> >

> > Hi Ard,

> >

> > I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough

> > test for them (IA32/X64 for my concern).

> >

> 

> For all other architectures, MAX_ADDRESS == MAX_ALLOC_ADDRESS is

> always true, so these changes only affect AARCH64.

> 

> > In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS

> > in MemoryAllocationLib like following situation?

> >

> > (MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c)

> > VOID *

> > InternalAllocateCopyPool (

> >   IN EFI_MEMORY_TYPE  PoolType,

> >   IN UINTN            AllocationSize,

> >   IN CONST VOID       *Buffer

> >   )

> > {

> >   VOID  *Memory;

> >

> >   ASSERT (Buffer != NULL);

> >   ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1));

> >   ...

> 

> This assert ensures that the copied buffer does not extend across the

> end of the address space and wraps. This is a separate concern, and is

> similar to numerous other occurrences of MAX_ADDRESS that maybe we

> should update as well at some point. However, it does not affect page

> allocation at all, it only puts an upper bound on the *size* of the

> allocation. So the changes as they are will be sufficient to ensure

> that AllocateCopyPool() does not allocate from a region that is not

> addressable by the CPU.

> _______________________________________________

> edk2-devel mailing list

> edk2-devel@lists.01.org

> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Ard Biesheuvel Dec. 10, 2018, 2:53 p.m. | #4
On Mon, 10 Dec 2018 at 15:52, Gao, Liming <liming.gao@intel.com> wrote:
>

> Ard:

>   I prefer to define MAX_ALLOC_ADDRESS together with MAX_ADDRESS in ProcessorBind.h. I don't want to leave the choice to override MAX_ALLOC_ADDRESS definition.

>


Seems reasonable. What should be the value for X64?

> Thanks

> Liming

> > -----Original Message-----

> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel

> > Sent: Monday, December 10, 2018 3:23 PM

> > To: Wang, Jian J <jian.j.wang@intel.com>

> > Cc: Andrew Jones <drjones@redhat.com>; Wu, Hao A <hao.a.wu@intel.com>; edk2-devel@lists.01.org; Gao, Liming

> > <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>

> > Subject: Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account

> >

> > On Mon, 10 Dec 2018 at 03:04, Wang, Jian J <jian.j.wang@intel.com> wrote:

> > >

> > > Hi Ard,

> > >

> > > I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough

> > > test for them (IA32/X64 for my concern).

> > >

> >

> > For all other architectures, MAX_ADDRESS == MAX_ALLOC_ADDRESS is

> > always true, so these changes only affect AARCH64.

> >

> > > In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS

> > > in MemoryAllocationLib like following situation?

> > >

> > > (MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c)

> > > VOID *

> > > InternalAllocateCopyPool (

> > >   IN EFI_MEMORY_TYPE  PoolType,

> > >   IN UINTN            AllocationSize,

> > >   IN CONST VOID       *Buffer

> > >   )

> > > {

> > >   VOID  *Memory;

> > >

> > >   ASSERT (Buffer != NULL);

> > >   ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1));

> > >   ...

> >

> > This assert ensures that the copied buffer does not extend across the

> > end of the address space and wraps. This is a separate concern, and is

> > similar to numerous other occurrences of MAX_ADDRESS that maybe we

> > should update as well at some point. However, it does not affect page

> > allocation at all, it only puts an upper bound on the *size* of the

> > allocation. So the changes as they are will be sufficient to ensure

> > that AllocateCopyPool() does not allocate from a region that is not

> > addressable by the CPU.

> > _______________________________________________

> > edk2-devel mailing list

> > edk2-devel@lists.01.org

> > https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Gao, Liming Dec. 10, 2018, 2:57 p.m. | #5
Keep the same value of MAX_ADDRESS. There is no change now. 

Thanks
Liming
> -----Original Message-----

> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]

> Sent: Monday, December 10, 2018 10:54 PM

> To: Gao, Liming <liming.gao@intel.com>

> Cc: Wang, Jian J <jian.j.wang@intel.com>; Andrew Jones <drjones@redhat.com>; Wu, Hao A <hao.a.wu@intel.com>;

> edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>

> Subject: Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account

> 

> On Mon, 10 Dec 2018 at 15:52, Gao, Liming <liming.gao@intel.com> wrote:

> >

> > Ard:

> >   I prefer to define MAX_ALLOC_ADDRESS together with MAX_ADDRESS in ProcessorBind.h. I don't want to leave the choice to

> override MAX_ALLOC_ADDRESS definition.

> >

> 

> Seems reasonable. What should be the value for X64?

> 

> > Thanks

> > Liming

> > > -----Original Message-----

> > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel

> > > Sent: Monday, December 10, 2018 3:23 PM

> > > To: Wang, Jian J <jian.j.wang@intel.com>

> > > Cc: Andrew Jones <drjones@redhat.com>; Wu, Hao A <hao.a.wu@intel.com>; edk2-devel@lists.01.org; Gao, Liming

> > > <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>

> > > Subject: Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account

> > >

> > > On Mon, 10 Dec 2018 at 03:04, Wang, Jian J <jian.j.wang@intel.com> wrote:

> > > >

> > > > Hi Ard,

> > > >

> > > > I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough

> > > > test for them (IA32/X64 for my concern).

> > > >

> > >

> > > For all other architectures, MAX_ADDRESS == MAX_ALLOC_ADDRESS is

> > > always true, so these changes only affect AARCH64.

> > >

> > > > In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS

> > > > in MemoryAllocationLib like following situation?

> > > >

> > > > (MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c)

> > > > VOID *

> > > > InternalAllocateCopyPool (

> > > >   IN EFI_MEMORY_TYPE  PoolType,

> > > >   IN UINTN            AllocationSize,

> > > >   IN CONST VOID       *Buffer

> > > >   )

> > > > {

> > > >   VOID  *Memory;

> > > >

> > > >   ASSERT (Buffer != NULL);

> > > >   ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1));

> > > >   ...

> > >

> > > This assert ensures that the copied buffer does not extend across the

> > > end of the address space and wraps. This is a separate concern, and is

> > > similar to numerous other occurrences of MAX_ADDRESS that maybe we

> > > should update as well at some point. However, it does not affect page

> > > allocation at all, it only puts an upper bound on the *size* of the

> > > allocation. So the changes as they are will be sufficient to ensure

> > > that AllocateCopyPool() does not allocate from a region that is not

> > > addressable by the CPU.

> > > _______________________________________________

> > > edk2-devel mailing list

> > > edk2-devel@lists.01.org

> > > https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Patch

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index 961c5b833546..5ad8e1171ef7 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -52,26 +52,26 @@  LIST_ENTRY   mFreeMemoryMapEntryList = INITIALIZE_LIST_HEAD_VARIABLE (mFreeMemor
 BOOLEAN      mMemoryTypeInformationInitialized = FALSE;
 
 EFI_MEMORY_TYPE_STATISTICS mMemoryTypeStatistics[EfiMaxMemoryType + 1] = {
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  // EfiReservedMemoryType
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiLoaderCode
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiLoaderData
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiBootServicesCode
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiBootServicesData
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  // EfiRuntimeServicesCode
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  // EfiRuntimeServicesData
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiConventionalMemory
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiUnusableMemory
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  // EfiACPIReclaimMemory
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  // EfiACPIMemoryNVS
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiMemoryMappedIO
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiMemoryMappedIOPortSpace
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  // EfiPalCode
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiPersistentMemory
-  { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }   // EfiMaxMemoryType
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  // EfiReservedMemoryType
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiLoaderCode
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiLoaderData
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiBootServicesCode
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiBootServicesData
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  // EfiRuntimeServicesCode
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  // EfiRuntimeServicesData
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiConventionalMemory
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiUnusableMemory
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  // EfiACPIReclaimMemory
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  FALSE },  // EfiACPIMemoryNVS
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiMemoryMappedIO
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiMemoryMappedIOPortSpace
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE,  TRUE  },  // EfiPalCode
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE },  // EfiPersistentMemory
+  { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }   // EfiMaxMemoryType
 };
 
-EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ADDRESS;
-EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ADDRESS;
+EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ALLOC_ADDRESS;
+EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ALLOC_ADDRESS;
 
 EFI_MEMORY_TYPE_INFORMATION gMemoryTypeInformation[EfiMaxMemoryType + 1] = {
   { EfiReservedMemoryType,      0 },
@@ -419,7 +419,7 @@  PromoteMemoryResource (
     Entry = CR (Link, EFI_GCD_MAP_ENTRY, Link, EFI_GCD_MAP_SIGNATURE);
 
     if (Entry->GcdMemoryType == EfiGcdMemoryTypeReserved &&
-        Entry->EndAddress < MAX_ADDRESS &&
+        Entry->EndAddress < MAX_ALLOC_ADDRESS &&
         (Entry->Capabilities & (EFI_MEMORY_PRESENT | EFI_MEMORY_INITIALIZED | EFI_MEMORY_TESTED)) ==
           (EFI_MEMORY_PRESENT | EFI_MEMORY_INITIALIZED)) {
       //
@@ -640,7 +640,7 @@  CoreAddMemoryDescriptor (
               gMemoryTypeInformation[FreeIndex].NumberOfPages
               );
             mMemoryTypeStatistics[Type].BaseAddress    = 0;
-            mMemoryTypeStatistics[Type].MaximumAddress = MAX_ADDRESS;
+            mMemoryTypeStatistics[Type].MaximumAddress = MAX_ALLOC_ADDRESS;
           }
         }
         return;
@@ -697,7 +697,7 @@  CoreAddMemoryDescriptor (
       }
     }
     mMemoryTypeStatistics[Type].CurrentNumberOfPages = 0;
-    if (mMemoryTypeStatistics[Type].MaximumAddress == MAX_ADDRESS) {
+    if (mMemoryTypeStatistics[Type].MaximumAddress == MAX_ALLOC_ADDRESS) {
       mMemoryTypeStatistics[Type].MaximumAddress = mDefaultMaximumAddress;
     }
   }
@@ -1318,15 +1318,15 @@  CoreInternalAllocatePages (
   //
   // The max address is the max natively addressable address for the processor
   //
-  MaxAddress = MAX_ADDRESS;
+  MaxAddress = MAX_ALLOC_ADDRESS;
 
   //
   // Check for Type AllocateAddress,
   // if NumberOfPages is 0 or
-  // if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ADDRESS or
+  // if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ALLOC_ADDRESS or
   // if (Start + NumberOfBytes) rolls over 0 or
-  // if Start is above MAX_ADDRESS or
-  // if End is above MAX_ADDRESS,
+  // if Start is above MAX_ALLOC_ADDRESS or
+  // if End is above MAX_ALLOC_ADDRESS,
   // return EFI_NOT_FOUND.
   //
   if (Type == AllocateAddress) {
@@ -1968,7 +1968,7 @@  CoreAllocatePoolPages (
   //
   // Find the pages to convert
   //
-  Start = FindFreePages (MAX_ADDRESS, NumberOfPages, PoolType, Alignment,
+  Start = FindFreePages (MAX_ALLOC_ADDRESS, NumberOfPages, PoolType, Alignment,
                          NeedGuard);
 
   //