Tianocore/edk2.git/MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib, branch edk2_master

MdeModulePkg: Apply uncrustify changes

2021-12-07T17:24:28+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the MdeModulePkg package Cc: Andrew Fish Cc: Leif Lindholm Cc: Michael D Kinney Signed-off-by: Michael Kubacki Reviewed-by: Liming Gao

MdeModulePkg: Replace BSD License with BSD+Patent License

2019-04-09T17:58:08+00:00

https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney Reviewed-by: Hao Wu Reviewed-by: Jian J Wang

MdeModulePkg: Clean up source files

2018-06-28T03:19:45+00:00

1. Do not use tab characters 2. No trailing white space in one line 3. All files must end with CRLF Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Reviewed-by: Star Zeng

MdeModulePkg PiSmmCoreMemoryAllocLib: Fix a FreePool() assertion issue

2017-08-01T09:44:02+00:00

When PiSmmCore links against PeiDxeDebugLibReportStatusCode, the code flow below will cause a FreePool() assertion issue. PiSmmCoreMemoryAllocationLibConstructor() -> SmmInitializeMemoryServices() -> DEBUG ((DEBUG_INFO, "SmmAddMemoryRegion\n")) in SmmAddMemoryRegion() -> DebugPrint() -> REPORT_STATUS_CODE_EX() -> ReportStatusCodeEx() -> AllocatePool()/FreePool(PiSmmCoreMemoryAllocLib) -> ASSERT() at Head = CR (Buffer, POOL_HEAD, Data, POOL_HEAD_SIGNATURE) in CoreFreePoolI() of DxeCore Pool.c It is because at the point of FreePool() in the code flow above, mSmmCoreMemoryAllocLibSmramRanges/mSmmCoreMemoryAllocLibSmramRangeCount are not been initialized yet, the FreePool() will be directed to gBS->FreePool(), that is wrong. This patch is to temporarily use BootServicesData to hold the SmramRanges data before calling SmmInitializeMemoryServices(). Cc: Liming Gao Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng Reviewed-by: Liming Gao

MdeModulePkg: Refine casting expression result to bigger size

2017-03-06T06:33:20+00:00

There are cases that the operands of an expression are all with rank less than UINT64/INT64 and the result of the expression is explicitly cast to UINT64/INT64 to fit the target size. An example will be: UINT32 a,b; // a and b can be any unsigned int type with rank less than UINT64, like // UINT8, UINT16, etc. UINT64 c; c = (UINT64) (a + b); Some static code checkers may warn that the expression result might overflow within the rank of "int" (integer promotions) and the result is then cast to a bigger size. The commit refines codes by the following rules: 1). When the expression is possible to overflow the range of unsigned int/ int: c = (UINT64)a + b; 2). When the expression will not overflow within the rank of "int", remove the explicit type casts: c = a + b; 3). When the expression will be cast to pointer of possible greater size: UINT32 a,b; VOID *c; c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b); 4). When one side of a comparison expression contains only operands with rank less than UINT32: UINT8 a; UINT16 b; UINTN c; if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...} For rule 4), if we remove the 'UINTN' type cast like: if (a + b > c) {...} The VS compiler will complain with warning C4018 (signed/unsigned mismatch, level 3 warning) due to promoting 'a + b' to type 'int'. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu Reviewed-by: Feng Tian

MdeModulePkg/Library: Fix typos in comments and variables

2016-10-27T01:11:19+00:00

- servity -> severity - TURE -> TRUE - contiue -> continue - Pepresentation -> Representation - suported -> supported - opints -> points - sucessfully -> successfully - hexidecimal -> hexadecimal - Pacakge -> Package - Libary -> Library - successull -> successfully - reseting -> resetting - Retrive -> Retrieve - dirver -> driver - availible -> available - chracter -> character - seperator -> separator Cc: Feng Tian Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin Reviewed-by: Feng Tian Reviewed-by: Star Zeng

MdeModulePkg PiSmmCoreMemoryAllocLib: Extend to support MemoryProfileLib

2016-07-01T01:39:59+00:00

Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng Reviewed-by: Jiewen Yao

MdeModulePkg: Convert all .uni files to utf-8

2015-12-15T04:56:23+00:00

To convert these files I ran: $ python3 BaseTools/Scripts/ConvertUni.py MdeModulePkg Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Reviewed-by: Michael Kinney Reviewed-by: Feng Tian git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19257 6f19259b-4bc3-4df7-8a09-765794883524

MdeModulePkg PiSmmCore: Remove a hidden assumption of SMRAM reservation

2015-07-26T07:38:12+00:00

that assumes the SMRAM reserved range is only at the end of the SMRAM descriptor. // // This range has reserved area, calculate the left free size // gSmmCorePrivate->SmramRanges[Index].PhysicalSize = SmramResRegion->SmramReservedStart - gSmmCorePrivate->SmramRanges[Index].CpuStart; Imagine the following scenario where we just reserve the first page of the SMRAM range: SMRAM Descriptor: Start: 0x80000000 Size: 0x02000000 Reserved Range: Start: 0x80000000 Size: 0x00001000 In this case the adjustment to the SMRAM range size yields zero: ReservedStart - SMRAM Start is 0x80000000 - 0x80000000 = 0. So even though most of the range is still free the IPL code decides its unusable. The problem comes from the email thread: [edk2] PiSmmIpl SMRAM Reservation Logic. http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15268 Also to follow the idea in the email thread, the patch is to 1. Keep only one copy of full SMRAM ranges in gSmmCorePrivate->SmramRanges, split record for SmmConfiguration->SmramReservedRegions and SMM Core that will be marked to be EFI_ALLOCATED in gSmmCorePrivate->SmramRanges. 2. Handle SmmConfiguration->SmramReservedRegions at beginning of, at end of, in the middle of, or cross multiple SmramRanges. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng Reviewed-by: Jiewen Yao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18031 6f19259b-4bc3-4df7-8a09-765794883524

MdeModulePkg: Enhance the comments for PiSmmCoreMemoryAllocationLib instance.

2015-06-19T01:58:09+00:00

Per PI spec all allocation of SMRAM should use EfiRuntimeServicesCode or EfiRuntimeServicesData. So SMM instance use EfiRuntimeServicesCode as the default memory allocation type instead of EfiBootServicesData. This patch clarify this usage in comments. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qiu Shumin Reviewed-by: Liming Gao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17667 6f19259b-4bc3-4df7-8a09-765794883524