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

["Michael D Kinney" <michael.d.kinney@intel.com>]

Hi Laszlo,

Responses below.

Mike

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Wednesday, January 24, 2024 6:17 AM
> To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Liming Gao <gaoliming@byosoft.com.cn>; Li, Aaron
> <aaron.li@intel.com>; Liu, Yun Y <yun.y.liu@intel.com>; Andrew Fish
> <afish@apple.com>
> Subject: Re: [edk2-devel] [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set
> MemoryTypeInfo bin range from HOB
> 
> 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:

I will extend the description of the GUID in MemoryTypeInformation.h

> 
> > /** @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.

I did consider doing this as a separate patch because the change in the
order of init in DxeMain can be done independent of this new optional
feature.  I will break it out to make that clear and simpler to review.
The new feature does depend on this new order so it has to be the first
patch.

> 
> >
> > 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().


Agreed.  I will remove that ineffective assignment and do that in the
first patch.

> 
> 
> > 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?

I am just being defensive in case code in the future attempts to call this
service more than one time.  This service should only be called one time
and any attempt to call again are ignored.  This is similar to the existing
behavior where the first call to CoreAddMemoryDescriptor() determines
the location of the bins and additional calls to CoreAddMemoryDescriptor()
skip the bin allocation logic.

I am also trying to avoid use of ASSERT() when possible due to overuse.

It may be better to have a DEBUG_ERROR message for this condition, so the
log shows that an attempt to set the memory type information location 
again was ignored.

> 
> > +
> > +  //
> > +  // 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.

I agree they are similar.  I did consider trying to consolidate the 
common logic to a single static helper function.  But there are differences
in the input conditions.  Current logic uses AllocatePages() to attempt
to allocate each bin.  And these allocations are not required to be
contiguous in memory.  They can be piecemeal extended as more memory is
registered until all the bins are allocated.  The memory type information
location from HOB is simpler because it is guaranteed to be a single
contiguous memory range.  This difference may a common helper function
much more challenging.

I was also concerned about inadvertently introducing a behavior change
when the memory type information location feature is not enabled.
Keeping the current code unmodified makes it easy from a review perspective
to know current behavior is preserved and allows a focus on reviewing
the new logic associated with the new feature.

> 
> Thanks,
> Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114345): https://edk2.groups.io/g/devel/message/114345
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]
-=-=-=-=-=-=-=-=-=-=-=-