Re: [edk2-devel] [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin range from HOB

["Laszlo Ersek" <lersek@redhat.com>]

On 1/23/24 21:24, Michael D Kinney wrote:
> Provide an optional method for PEI to declare a specific address
> range to use for the Memory Type Information bins. The current
> algorithm uses heuristics that tends to place the Memory Type
> Information bins in the same location, but memory configuration
> changes across boots or algorithm changes across a firmware
> updates could potentially change the Memory Type Information bin
> location.
>
> If the HOB List contains a Resource Descriptor HOB that
> describes tested system memory and has an Owner GUID of
> gEfiMemoryTypeInformationGuid, then use the address range
> described by the Resource Descriptor HOB as the preferred
> location of the Memory Type Information bins. If this HOB is
> not detected, then the current behavior is preserved.
>
> The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
> is ignored for the following conditions:
> * The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
>   is smaller than the Memory Type Information bins.
> * The HOB list contains more than one Resource Descriptor HOB
>   with an owner GUID of gEfiMemoryTypeInformationGuid.
> * The Resource Descriptor HOB with an Owner GUID of
>   gEfiMemoryTypeInformationGuid is the same Resource Descriptor
>   HOB that that describes the PHIT memory range.

I feel that, while this GUID usage makes sense, it overloads the already
existing meanings of gEfiMemoryTypeInformationGuid.

We already use this GUID for two things:

(see "MdeModulePkg/Include/Guid/MemoryTypeInformation.h"):

- UEFI variable name space GUID for the "MemoryTypeInformation" variable

- HOB of type EFI_HOB_TYPE_GUID_EXTENSION, controlling the page counts
in the various memory type bins.

Now this new use would introduce a HOB of type
EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, where the Owner field is
gEfiMemoryTypeInformationGuid, and the range described by the
PhysicalStart and ResourceLength fields would accommodate the actual
bins. On one hand this new HOB is certainly related to the prior two
uses, but on the other hand, we'd now have to HOBs that used the "same
GUID" for different purposes. What distinguishes them is
EFI_HOB_TYPE_GUID_EXTENSION vs. EFI_HOB_TYPE_RESOURCE_DESCRIPTOR --
which I find a bit too obscure.

(1) So I'd either suggest generating a brand new GUID, *or* extending the
comments in "MdeModulePkg/Include/Guid/MemoryTypeInformation.h" with the
new usage:

> /** @file
>   This file defines:
>   * Memory Type Information GUID for HOB and Variable.
>   * Memory Type Information Variable Name.
>   * Memory Type Information GUID HOB data structure.
>
>   The memory type information HOB and variable can
>   be used to store the information for each memory type in Variable or HOB.
>
> Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>
> SPDX-License-Identifier: BSD-2-Clause-Patent
>
> **/

Back to the patch:

On 1/23/24 21:24, Michael D Kinney wrote:
> Update the DxeMain initialization order to initialize GCD
> services before any runtime allocations are performed.  This
> is required to prevent runtime data fragmentation when the
> UEFI System Table and UEFI Runtime Service Table is allocated.

(2) Should this be a separate patch? (First patch in the series?) This seems
to effect behavior even if the new HOB is not present.

>
> Cc: Liming Gao <gaoliming@byosoft.com.cn>
> Cc: Aaron Li <aaron.li@intel.com>
> Cc: Liu Yun <yun.y.liu@intel.com>
> Cc: Andrew Fish <afish@apple.com>
> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
> ---
>  MdeModulePkg/Core/Dxe/DxeMain.h         |   6 ++
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c |  23 +++---
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c         |  72 ++++++++++++++++-
>  MdeModulePkg/Core/Dxe/Mem/Page.c        | 101 ++++++++++++++++++++++++
>  4 files changed, 190 insertions(+), 12 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h
> index 86a7be2f5188..53e26703f8c7 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain.h
> +++ b/MdeModulePkg/Core/Dxe/DxeMain.h
> @@ -277,6 +277,12 @@ CoreInitializePool (
>    VOID
>    );
>
> +VOID
> +CoreSetMemoryTypeInformationRange (
> +  IN EFI_PHYSICAL_ADDRESS  Start,
> +  IN UINT64                Length
> +  );
> +
>  /**
>    Called to initialize the memory map and add descriptors to
>    the current descriptor list.
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> index 0e0f9769b99d..17d510a287e5 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> +++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> @@ -276,6 +276,18 @@ DxeMain (
>
>    MemoryProfileInit (HobStart);
>
> +  //
> +  // Start the Image Services.
> +  //
> +  Status = CoreInitializeImageServices (HobStart);
> +  ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // Initialize the Global Coherency Domain Services
> +  //
> +  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress, MemoryLength);
> +  ASSERT_EFI_ERROR (Status);
> +
>    //
>    // Allocate the EFI System Table and EFI Runtime Service Table from EfiRuntimeServicesData
>    // Use the templates to initialize the contents of the EFI System Table and EFI Runtime Services Table
> @@ -289,16 +301,9 @@ DxeMain (
>    gDxeCoreST->RuntimeServices = gDxeCoreRT;
>
>    //
> -  // Start the Image Services.
> +  // Update DXE Core Loaded Image Protocol with allocated UEFI System Table
>    //
> -  Status = CoreInitializeImageServices (HobStart);
> -  ASSERT_EFI_ERROR (Status);
> -
> -  //
> -  // Initialize the Global Coherency Domain Services
> -  //
> -  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress, MemoryLength);
> -  ASSERT_EFI_ERROR (Status);
> +  gDxeCoreLoadedImage->SystemTable = gDxeCoreST;
>
>    //
>    // Call constructor for all libraries

(3) The separate assignment to "gDxeCoreLoadedImage->SystemTable"
becomes necessary because CoreInitializeImageServices() is hoisted above

  gDxeCoreST = AllocateRuntimeCopyPool (sizeof (EFI_SYSTEM_TABLE), &mEfiSystemTableTemplate);

and therefore the assignment

  Image->Info.SystemTable = gDxeCoreST;

in CoreInitializeImageServices() becomes ineffective -- at that time,
gDxeCoreST is NULL, post-patch.

This double-write (overwrite) to the SystemTable field is confusing. I
propose (again, in said separate, first patch) the removal of the
now-ineffective assignment from CoreInitializeImageServices().


> diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> index 792cd2e0af23..c450d1bf2531 100644
> --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> @@ -2238,6 +2238,8 @@ CoreInitializeMemoryServices (
>    EFI_HOB_HANDOFF_INFO_TABLE   *PhitHob;
>    EFI_HOB_RESOURCE_DESCRIPTOR  *ResourceHob;
>    EFI_HOB_RESOURCE_DESCRIPTOR  *PhitResourceHob;
> +  EFI_HOB_RESOURCE_DESCRIPTOR  *MemoryTypeInformationResourceHob;
> +  UINTN                        Count;
>    EFI_PHYSICAL_ADDRESS         BaseAddress;
>    UINT64                       Length;
>    UINT64                       Attributes;
> @@ -2289,12 +2291,47 @@ CoreInitializeMemoryServices (
>    //
>    // See if a Memory Type Information HOB is available
>    //
> -  GuidHob = GetFirstGuidHob (&gEfiMemoryTypeInformationGuid);
> +  MemoryTypeInformationResourceHob = NULL;
> +  GuidHob                          = GetFirstGuidHob (&gEfiMemoryTypeInformationGuid);
>    if (GuidHob != NULL) {
>      EfiMemoryTypeInformation = GET_GUID_HOB_DATA (GuidHob);
>      DataSize                 = GET_GUID_HOB_DATA_SIZE (GuidHob);
>      if ((EfiMemoryTypeInformation != NULL) && (DataSize > 0) && (DataSize <= (EfiMaxMemoryType + 1) * sizeof (EFI_MEMORY_TYPE_INFORMATION))) {
>        CopyMem (&gMemoryTypeInformation, EfiMemoryTypeInformation, DataSize);
> +
> +      //
> +      // Look for Resource Descriptor HOB with a ResourceType of System Memory
> +      // and an Owner GUID of gEfiMemoryTypeInformationGuid. If more than 1 is
> +      // found, then set MemoryTypeInformationResourceHob to NULL.
> +      //
> +      Count = 0;
> +      for (Hob.Raw = *HobStart; !END_OF_HOB_LIST (Hob); Hob.Raw = GET_NEXT_HOB (Hob)) {
> +        if (GET_HOB_TYPE (Hob) != EFI_HOB_TYPE_RESOURCE_DESCRIPTOR) {
> +          continue;
> +        }
> +
> +        ResourceHob = Hob.ResourceDescriptor;
> +        if (!CompareGuid (&ResourceHob->Owner, &gEfiMemoryTypeInformationGuid)) {
> +          continue;
> +        }
> +
> +        Count++;
> +        if (ResourceHob->ResourceType != EFI_RESOURCE_SYSTEM_MEMORY) {
> +          continue;
> +        }
> +
> +        if ((ResourceHob->ResourceAttribute & MEMORY_ATTRIBUTE_MASK) != TESTED_MEMORY_ATTRIBUTES) {
> +          continue;
> +        }
> +
> +        if (ResourceHob->ResourceLength >= CalculateTotalMemoryBinSizeNeeded ()) {
> +          MemoryTypeInformationResourceHob = ResourceHob;
> +        }
> +      }
> +
> +      if (Count > 1) {
> +        MemoryTypeInformationResourceHob = NULL;
> +      }
>      }
>    }
>
> @@ -2344,6 +2381,15 @@ CoreInitializeMemoryServices (
>      PhitResourceHob = ResourceHob;
>      Found           = TRUE;
>
> +    //
> +    // If a Memory Type Information Resource HOB was found and is the same
> +    // Resource HOB that describes the PHIT HOB, then ignore the Memory Type
> +    // Information Resource HOB.
> +    //
> +    if (MemoryTypeInformationResourceHob == PhitResourceHob) {
> +      MemoryTypeInformationResourceHob = NULL;
> +    }
> +
>      //
>      // Compute range between PHIT EfiMemoryTop and the end of the Resource Descriptor HOB
>      //
> @@ -2387,8 +2433,9 @@ CoreInitializeMemoryServices (
>    if (Length < MinimalMemorySizeNeeded) {
>      //
>      // Search all the resource descriptor HOBs from the highest possible addresses down for a memory
> -    // region that is big enough to initialize the DXE core.  Always skip the PHIT Resource HOB.
> -    // The max address must be within the physically addressible range for the processor.
> +    // region that is big enough to initialize the DXE core.  Always skip the PHIT Resource HOB
> +    // and the Memory Type Information Resource HOB. The max address must be within the physically
> +    // addressable range for the processor.
>      //
>      HighAddress = MAX_ALLOC_ADDRESS;
>      for (Hob.Raw = *HobStart; !END_OF_HOB_LIST (Hob); Hob.Raw = GET_NEXT_HOB (Hob)) {
> @@ -2399,6 +2446,13 @@ CoreInitializeMemoryServices (
>          continue;
>        }
>
> +      //
> +      // Skip the Resource Descriptor HOB that contains Memory Type Information bins
> +      //
> +      if (Hob.ResourceDescriptor == MemoryTypeInformationResourceHob) {
> +        continue;
> +      }
> +
>        //
>        // Skip all HOBs except Resource Descriptor HOBs
>        //
> @@ -2466,6 +2520,18 @@ CoreInitializeMemoryServices (
>      Capabilities = CoreConvertResourceDescriptorHobAttributesToCapabilities (EfiGcdMemoryTypeSystemMemory, Attributes);
>    }
>
> +  if (MemoryTypeInformationResourceHob != NULL) {
> +    //
> +    // If a Memory Type Information Resource HOB was found, then use the address
> +    // range of the  Memory Type Information Resource HOB as the preferred
> +    // address range for the Memory Type Information bins.
> +    //
> +    CoreSetMemoryTypeInformationRange (
> +      MemoryTypeInformationResourceHob->PhysicalStart,
> +      MemoryTypeInformationResourceHob->ResourceLength
> +      );
> +  }
> +
>    //
>    // Declare the very first memory region, so the EFI Memory Services are available.
>    //

Hmm, I think I have a coarse understanding of the control flow here. If
we call CoreSetMemoryTypeInformationRange() here -- due to the new HOB
being available --, then "mMemoryTypeInformationInitialized" will be set
to TRUE. Then, the very first call to CoreAddMemoryDescriptor(), just
below the context quoted above, will see
"mMemoryTypeInformationInitialized" as TRUE, and avoid iterating through
the memory type information array. OK.

> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index 6497af573353..458c62090265 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -532,6 +532,107 @@ CoreLoadingFixedAddressHook (
>    return;
>  }
>
> +/**
> +  Sets the preferred memory range to use for the Memory Type Information bins.
> +  This service must be called before fist call to CoreAddMemoryDescriptor().
> +
> +  If the location of the Memory Type Information bins has already been
> +  established or the size of the range provides is smaller than all the
> +  Memory Type Information bins, then the range provides is not used.
> +
> +  @param  Start   The start address of the Memory Type Information range.
> +  @param  Length  The size, in bytes, of the Memory Type Information range.
> +**/
> +VOID
> +CoreSetMemoryTypeInformationRange (
> +  IN EFI_PHYSICAL_ADDRESS  Start,
> +  IN UINT64                Length
> +  )
> +{
> +  EFI_PHYSICAL_ADDRESS  Top;
> +  EFI_MEMORY_TYPE       Type;
> +  UINTN                 Index;
> +  UINTN                 Size;
> +
> +  //
> +  // Return if Memory Type Information bin locations have already been set
> +  //
> +  if (mMemoryTypeInformationInitialized) {
> +    return;
> +  }

(4) Under what circumstances can this condition evaluate to TRUE?

Should we perhaps

  ASSERT (!mMemoryTypeInformationInitialized);

instead?

> +
> +  //
> +  // Return if size of the Memory Type Information bins is greater than Length
> +  //
> +  Size = 0;
> +  for (Index = 0; gMemoryTypeInformation[Index].Type != EfiMaxMemoryType; Index++) {
> +    //
> +    // Make sure the memory type in the gMemoryTypeInformation[] array is valid
> +    //
> +    Type = (EFI_MEMORY_TYPE)(gMemoryTypeInformation[Index].Type);
> +    if ((UINT32)Type > EfiMaxMemoryType) {
> +      continue;
> +    }
> +
> +    Size += EFI_PAGES_TO_SIZE (gMemoryTypeInformation[Index].NumberOfPages);
> +  }
> +
> +  if (Size > Length) {
> +    return;
> +  }
> +
> +  //
> +  // Loop through each memory type in the order specified by the
> +  // gMemoryTypeInformation[] array
> +  //
> +  Top = Start + Length;
> +  for (Index = 0; gMemoryTypeInformation[Index].Type != EfiMaxMemoryType; Index++) {
> +    //
> +    // Make sure the memory type in the gMemoryTypeInformation[] array is valid
> +    //
> +    Type = (EFI_MEMORY_TYPE)(gMemoryTypeInformation[Index].Type);
> +    if ((UINT32)Type > EfiMaxMemoryType) {
> +      continue;
> +    }
> +
> +    if (gMemoryTypeInformation[Index].NumberOfPages != 0) {
> +      mMemoryTypeStatistics[Type].MaximumAddress = Top - 1;
> +      Top                                       -= EFI_PAGES_TO_SIZE (gMemoryTypeInformation[Index].NumberOfPages);
> +      mMemoryTypeStatistics[Type].BaseAddress    = Top;
> +
> +      //
> +      // If the current base address is the lowest address so far, then update
> +      // the default maximum address
> +      //
> +      if (mMemoryTypeStatistics[Type].BaseAddress < mDefaultMaximumAddress) {
> +        mDefaultMaximumAddress = mMemoryTypeStatistics[Type].BaseAddress - 1;
> +      }
> +
> +      mMemoryTypeStatistics[Type].NumberOfPages   = gMemoryTypeInformation[Index].NumberOfPages;
> +      gMemoryTypeInformation[Index].NumberOfPages = 0;
> +    }
> +  }
> +
> +  //
> +  // If the number of pages reserved for a memory type is 0, then all
> +  // allocations for that type should be in the default range.
> +  //
> +  for (Type = (EFI_MEMORY_TYPE)0; Type < EfiMaxMemoryType; Type++) {
> +    for (Index = 0; gMemoryTypeInformation[Index].Type != EfiMaxMemoryType; Index++) {
> +      if (Type == (EFI_MEMORY_TYPE)gMemoryTypeInformation[Index].Type) {
> +        mMemoryTypeStatistics[Type].InformationIndex = Index;
> +      }
> +    }
> +
> +    mMemoryTypeStatistics[Type].CurrentNumberOfPages = 0;
> +    if (mMemoryTypeStatistics[Type].MaximumAddress == MAX_ALLOC_ADDRESS) {
> +      mMemoryTypeStatistics[Type].MaximumAddress = mDefaultMaximumAddress;
> +    }
> +  }
> +
> +  mMemoryTypeInformationInitialized = TRUE;
> +}
> +
>  /**
>    Called to initialize the memory map and add descriptors to
>    the current descriptor list.

This part resembles (and seems to substitute for) the tail of said very
first CoreAddMemoryDescriptor() execution. There are some differences;
here we don't rely on CoreAllocatePages(). I don't understand either
piece of code enough for making a meaningful comparison. The general
control flow separation seems sane, modulo my question (4) above.

Thanks,
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114300): https://edk2.groups.io/g/devel/message/114300
Mute This Topic: https://groups.io/mt/103918464/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-