Re: Question about memory map entries

[Rafael Machado <rafaelrodrigues.machado@gmail.com>]

Hi Andrew.

Thanks for the clarification!

Rafael

Em qua, 8 de ago de 2018 às 16:14, Andrew Fish <afish@apple.com> escreveu:

>
> On Aug 8, 2018, at 10:31 AM, Rafael Machado <
> rafaelrodrigues.machado@gmail.com> wrote:
>
> Hi everyone
>
> One question that was not answered and that could help us, is about
> skipping the MemoryTypeInfo variable usage.
> Is there any way to do this skip at a UEFI App ?
> Simple erasing the MemoryTypeInfo  var seems a little to violent from our
> perspective. What do you think?
>
> Seems the system we're having this problem has some inconsistency when
> filling the MemoryTypeInfo  var before exiting the previous boot, and
> seems to consider the BootServices memory type also to be stored at the
> var. Does anyone remember of this kind of issue on some system in the past?
>
>
> No we do that all the time to remove fragmentation from the memory map and
> it does not
>
> Thanks,
>
> Andrew Fish
>
> Thanks and Regards
> Rafael
>
> Em qua, 8 de ago de 2018 às 08:55, Rafael Machado <
> rafaelrodrigues.machado@gmail.com> escreveu:
>
>> Hi Jiewen
>>
>> Thanks for highlighting this.
>> Just checked and we just add the Reserved/Acpi/Runtime types.
>>
>> Seems the guess that this would be related to the MemoryTypeInfo var is
>> not the correct way to follow.
>>
>> We'll keep working on it, maybe asking more questions to the community in
>> future.
>> Thank you all for the help and guidance!
>> In case someone has any comment or idea, please feel free to share.
>>
>> Rafael
>>
>>
>>
>> Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen <jiewen.yao@intel.com>
>> escreveu:
>>
>>> Hi
>>>
>>> It is unclear to me that which type you have put to MemoryTypeInfo table.
>>>
>>>
>>>
>>> By design, we only need put Reserved/Acpi/Runtime, which should be quite
>>> small.
>>>
>>>
>>>
>>> Do you put any other type into MemoryTypeInfo table?
>>>
>>>
>>>
>>> Thank you
>>>
>>> Yao Jiewen
>>>
>>>
>>>
>>> *From:* Rafael Machado [mailto:rafaelrodrigues.machado@gmail.com]
>>> *Sent:* Wednesday, August 8, 2018 3:12 AM
>>> *To:* Laszlo Ersek <lersek@redhat.com>
>>> *Cc:* Andrew Fish <afish@apple.com>; Ni, Ruiyu <ruiyu.ni@intel.com>;
>>> edk2-devel@lists.01.org; Yao, Jiewen <jiewen.yao@intel.com>
>>>
>>>
>>> *Subject:* Re: [edk2] Question about memory map entries
>>>
>>>
>>>
>>> Hi everyone
>>>
>>>
>>>
>>> Based on the information shared by the members, the understanding is
>>> that the current state of the system may impact fuutre boots.
>>>
>>> The problem is that in my case, due to specific requirements, before
>>> booting we need to stress the system's memory, allocating a big amount of
>>> memory and doing some memory validation algorithms.
>>>
>>> So the high number of allocations and frees is by choice and not by
>>> mistakes.
>>>
>>>
>>>
>>> Considering this. Is there any way to bypass the MemoryTypeInformation
>>> var store actions?
>>>
>>>
>>>
>>> Thanks and Regards
>>>
>>> Rafael
>>>
>>>
>>>
>>> Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek <lersek@redhat.com>
>>> escreveu:
>>>
>>> On 08/02/18 21:18, Rafael Machado wrote:
>>> > Just found something interesting.
>>> > Based on the logs from the serial port.
>>> >
>>> > This system works fine:
>>> >
>>> > "PeiInstallPeiMemory MemoryBegin 0x93D50000, MemoryLength 0xA2B0000
>>> > Temp Stack : BaseAddress=0x400000 Length=0x80000
>>> > Temp Heap  : BaseAddress=0x480000 Length=0x80000
>>> > Total temporary memory:    1048576 bytes.
>>> >   temporary memory stack ever used: 524288 bytes.
>>> >   temporary memory heap used:       63304 bytes.
>>> > Old Stack size 524288, New stack size 524288
>>> > Stack Hob: BaseAddress=0x93D50000 Length=0x80000
>>> > Heap Offset = 0x93950000 Stack Offset = 0x93950000
>>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
>>> > ...
>>> > "CoreInitializeMemoryServices:
>>> >   BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
>>> > 0x5AC0000"
>>> >
>>> > This one is bricked:
>>> >
>>> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
>>> > Temp Stack : BaseAddress=0x400000 Length=0x80000
>>> > Temp Heap  : BaseAddress=0x480000 Length=0x80000
>>> > Total temporary memory:    1048576 bytes.
>>> >   temporary memory stack ever used: 524288 bytes.
>>> >   temporary memory heap used:       63304 bytes.
>>> > Old Stack size 524288, New stack size 524288
>>> > Stack Hob: BaseAddress=0x9C9000 Length=0x80000
>>> > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000
>>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
>>> > ...
>>> > "CoreInitializeMemoryServices:
>>> >   BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000
>>> > "
>>> > ...
>>> > "ASSERT_EFI_ERROR (Status = Out of Resources)
>>> > ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299):
>>> > !EFI_ERROR (Status)
>>> > AllocatePoolPages: failed to allocate 1 pages
>>> > AllocatePool: failed to allocate 120 bytes"
>>>
>>> The location and the size of the permanent PEI RAM are extremely
>>> different between the two cases.
>>>
>>> - Functional system:
>>>
>>>   PeiInstallPeiMemory MemoryBegin 0x93D50000, MemoryLength 0xA2B0000
>>>
>>>   Base address is ~2365 MB, size is ~162 MB
>>>
>>> - Unbootable system:
>>>
>>>   PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
>>>
>>>   Base address is ~9 MB, size is ~2518 MB
>>>
>>> The numbers in the second (unbootable) case look very unusual to me. The
>>> permanent PEI RAM is usually tens or (maybe) hundreds of megabytes in
>>> size, and tends to start much higher (usually as high as possible under
>>> 4GB, on x86 anyway).
>>>
>>>
>>> Consult the following sections in the PI spec (v1.6), volume 3:
>>>
>>> - 4.3 Example HOB Producer Phase Memory Map and Usage
>>> - 5.3 PHIT HOB
>>>
>>> The CoreInitializeMemoryServices() function searches the HOB list for a
>>> tested system memory "Resource Descriptor HOB that contains PHIT range
>>> EfiFreeMemoryBottom..EfiFreeMemoryTop". (Quoted a comment from the code.)
>>>
>>> Basically, the function locates the system RAM HOB that contains the
>>> free permanent PEI RAM.
>>>
>>> If the search fails, then we trip an ASSERT(). This does not happen in
>>> your case, the search succeeds.
>>>
>>> If the search succeeds, then the DXE core will try to initialize itself
>>> in one of three locations in the RAM area defined by that HOB. In
>>> descending preference order: above the permanent PEI RAM, within the
>>> free permanent PEI RAM, and below the permanent PEI RAM.
>>>
>>> There is also a fallback (a fourth option) when even the third one from
>>> before proves too small -- the function will then search again for a
>>> memory descriptor HOB, top-down, avoiding the one HOB that it found
>>> earlier to contain the permanent PEI RAM (because, all three options for
>>> that have already failed, see above).
>>>
>>> As the result of this search, your broken system finishes with:
>>>
>>> BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000
>>>
>>> "MinimalMemorySizeNeeded" includes the previous measurements from
>>> MemoryTypeInformation, and the concrete value is very strange -- it
>>> seems to imply that you need ~2446 MB for initializing the DXE core.
>>> It's not surprising that the function cannot fit that anywhere, in
>>> either of the four options described above.
>>>
>>> If your system has more (high) RAM to spare, try to install a resource
>>> descriptor HOB for it. Then the fourth option might succeed.
>>>
>>> Honestly though, those permanent PEI RAM values (base address at ~9 MB,
>>> size ~2518 MB) look super fishy to me in the first place. Something must
>>> be wrong in the PEI phase with the calculation of those parameters.
>>> Possibly, the memory resource descriptor HOBs could be wrong too.
>>>
>>>
>>> ... Considering commit 3a05b13106d1 ("MdeModulePkg DxeCore: Take the
>>> range in resource HOB for PHIT as higher priority", 2015-09-18), it
>>> writes,
>>>
>>> "Also let the minimal memory size needed include the total memory bin
>>> size needed to make sure memory bin could be allocated successfully."
>>>
>>> This is the reason "MinimalMemorySizeNeeded" includes
>>> MemoryTypeInformation. Normally, MemoryTypeInformation tracks long-term
>>> maximums that are necessary for booting an OS without memory map
>>> fragmentation (including S4 resume). However, if you have a UEFI
>>> application that allocates huge amounts of memory, and then *doesn't*
>>> boot an OS, then it could invalidate MemoryTypeInformation. Because, the
>>> maximums that MemoryTypeInformation represents, no longer reflect
>>> requirements for booting an OS. In that case, the
>>> "MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for
>>> initializing the DXE core, could be invalid too.
>>>
>>> Thanks
>>> Laszlo
>>>
>>>