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

Renormalized end-of-lines from master@27b044605cd5f6b33a3d231576003850b3fe305b

2024-06-04T03:43:08+00:00

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