Prevent VariablePei Memory Bucket Fragmentation

[makubacki]

Description

Fixes #11739

---

MdeModulePkg/Variable: Move RT cache buffer allocation to DXE

Commit d8f513de3e3ef228af7e6facf0ad3e35c3224032 added runtime
memory allocation to VariablePei. That will cause runtime memory
bucket fragmentation affecting hibernate stability as these runtime
allocations are separate from the main runtime memory type
bucket allocation made by the DXE Core.

To preserve the existing functionality but allow the runtime buffer
to come from the DXE bucket, the allocations in PEI are changed to
boot services data allocations and the contents are moved to the
runtime memory buffers (and those pages unblocked to MM) in the
DXE variable driver after the bucket has been allocated by the DXE
core.

---

MdeModulePkg/VariableSmmRuntimeDxe: Disable var RT cache on alloc failure

If a RT data buffer fails to be allocated or unblocked, clean up the
RT cache state by (1) freeing any allocated buffers and (2) resetting
the buffer addresses back to zero to indicate the RT cache is not
available.

---

• Breaking change?
• Impacts security?
• Includes tests?

How This Was Tested

• Boot with the UEFI variable runtime cache enabled on QEMU and a physical X64 platform

Integration Instructions

• M/A

[makubacki]

@lgao4 & @td36, I posted this PR to raise the issue and show a possible approach to address the problem.

Can you please clarify the requirements that are needed for the runtime cache allocation in the variable PEIM? If the runtime type memory allocation is required (cannot be done in DXE as proposed here), can you describe that use case? Then, we can determine what alternatives may be viable that support it and can prevent memory bucket fragmentation.

[makubacki]

@lgao4 & @td36 , please provide feedback on the change. I'd just like you to check if this direction is acceptable to you or if you would like to propose an alternative.

[lgao4]

@lgao4 & @td36 , please provide feedback on the change. I'd just like you to check if this direction is acceptable to you or if you would like to propose an alternative.

I don't think it is necessary to allocate runtime memory for variable in pei phase. I agree your proposal to migrate them in DXE phase from boot memory to runtime memory.

@niruiyu , have you any suggestion for this PR?

[niruiyu]

@lgao4 & @td36, I posted this PR to raise the issue and show a possible approach to address the problem.

Can you please clarify the requirements that are needed for the runtime cache allocation in the variable PEIM? If the runtime type memory allocation is required (cannot be done in DXE as proposed here), can you describe that use case? Then, we can determine what alternatives may be viable that support it and can prevent memory bucket fragmentation.

@makubacki The edk2 standalone MM does not accept Unblock request after it has been launched. A unblock request in PEI is translated to a GUIDed HOB and passed to standalone MM env for paging setup. A unblock request in DXE is ignored (actually there is no DXE version of Unblock implementation in edk2). The purpose of not accepting Unblock in DXE is for better security.

[niruiyu]

@lgao4 & @td36 , please provide feedback on the change. I'd just like you to check if this direction is acceptable to you or if you would like to propose an alternative.

I don't think it is necessary to allocate runtime memory for variable in pei phase. I agree your proposal to migrate them in DXE phase from boot memory to runtime memory.

@niruiyu , have you any suggestion for this PR?

As I mentioned above, migration to DXE does not work according to current standalone MM design.

[makubacki]

@niruiyu, I understand the edk2 Standalone MM design and it was the main reason for keeping this in draft to discuss a plan.

The requirement is the same as it has been since the concept of memory buckets was introduced and that is to keep runtime memory allocations stable across S4. Allocating runtime in memory in PEI prior to the DXE core establishing the buckets used for runtime memory allocations leads to fragmentation. What is the edk2 design answer for this?