Re: Question about memory map entries


Rafael Machado
 

Hi Andrew.

Thanks for the clarification!

Rafael

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


On Aug 8, 2018, at 10:31 AM, Rafael Machado <
rafaelrodrigues.machado@...> 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@...> 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@...>
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@...]
*Sent:* Wednesday, August 8, 2018 3:12 AM
*To:* Laszlo Ersek <lersek@...>
*Cc:* Andrew Fish <afish@...>; Ni, Ruiyu <ruiyu.ni@...>;
edk2-devel@...; Yao, Jiewen <jiewen.yao@...>


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

Join devel@edk2.groups.io to automatically receive all group messages.