Set the ImageContext.Handle and ImageContext.ImageRead() fields so that
PeCoffLoaderRelocateImageExtraAction() can invoke PeCoffLoaderGetImageInfo
or PeCoffLoaderGetPeHeader if desired to obtain additional metadata.
We will use this to create a PeCoffLoaderRelocateImageExtraAction()
implementation that applies boot time strict mapping permissions to
PE/COFF modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This patch enhance SMM memory profile SMM communication by using fixed
SMM communication buffer.
Update PiSmmCore to handle SMRAM_PROFILE_COMMAND_GET_PROFILE_DATA_BY_OFFSET
request.
This is designed to meet Microsoft WSMT table definition on FIXED_COMM_BUFFERS
requirement.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Use 128 bytes as the start size region to be same to previous one.
64 bytes is small as the first range. On X64 arch, POOL_OVERHEAD
takes 40 bytes, the pool data less than 24 bytes can be fit into
it. But, the real allocation is few that can't reduce its free pool
link list. And, the second range (64~128) has more allocation
that also increases the free pool link list of the first range.
Then, the link list will become longer and longer. When LinkList
check enable in DEBUG tip, the long link list will bring the
additional overhead and bad performance. Here is the performance
data collected in our X64 platform with DEBUG enable.
64 byte: 22 seconds in BDS phase
128 byte: 19.6 seconds in BDS phase
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
It can improve profile performance, especially when
PcdMemoryProfileMemoryType configured without EfiBootServicesData.
CoreUpdateProfile() can return quickly, but not depend on the further
code to find the buffer not recorded and then return.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The patch uses CoreAcquireLockOrFail() instead of
CoreAcquireProtocolLock() in CoreLocateProtocol() to avoid
assertion when CoreLocateProtocol() is called with the
protocol database locked.
The issue was found when changing PcdDebugPrintErrorLevel to
enable page/pool allocation debug message.
Nt32 platform hangs immediately after DxeCore is loaded.
Investigation shows the following calling stacks:
DxeCore entry point (Install a certain protocol)
0 DxeCore::CoreInstallProtocolInterface // Protocol DB is locked
1 DxeCore::AllocatePool
2 PeiDxeDebugLibReportStatusCode::DebugPrint
3 DxeReportStatusCodeLib::ReportStatusCodeEx // <-------------------|
4 DxeReportStatusCodeLib::InternalGetReportStatusCode |
5 DxeCore::LocateProtocol(StatusCodeRuntimeProtocol) |
// Assertion when locking Protocol DB 2nd time |
6 DxeCore::CoreAcquireProtocolLock |
7 PeiDxeDebugLibReportStatusCode::DebugAssert |
8 DxeReportStatusCodeLib::ReportSatusCodeEx // loop begins ---------
In frame #6 the assertion is triggered due to the protocol database
is already locked. #8 calls #4 and the loop begins.
After changing #6 to CoreAcquireLockOrFail(), the assertion is
avoided and the loop is broken.
With the fix, NT32 can boot to Shell even setting
PcdDebugPrintErrorLevel to 0xFFFFFFFF, with all error levels turned
on.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Current MemoryAttributesTable will be installed on ReadyToBoot event
at TPL_NOTIFY level, it maybe incorrect when PcdHiiOsRuntimeSupport
= TRUE as HiiDatabaseDxe will have runtime memory allocation for HII
OS runtime support on and after ReadyToBoot. The issue was exposed at
http://article.gmane.org/gmane.comp.bios.edk2.devel/10125.
To make sure the correctness of MemoryAttributesTable, this patch is
to enhance MemoryAttributesTable installation to install
MemoryAttributesTable on ReadyToBoot event at TPL_CALLBACK - 1 level
to make sure it is at the last of ReadyToBoot event, and also hook
runtime memory allocation after ReadyToBoot.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The following patch for MemoryAttributesTable will need the memory type.
And CoreUpdateProfile() can also use the memory type for check.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Originally, the code block for "Report DXE Core image information to the PE/COFF
Extra Action Library" was after ProcessLibraryConstructorList(). To fix an issue,
ProcessLibraryConstructorList() was moved to be right after CoreInitializeGcdServices()
at c5d5379937, but the code block was left.
As there maybe PeCoffExtraActionLib implementation need Constructor executed first,
the patch is to move the code block for "Report DXE Core image information to the PE/COFF
Extra Action Library" to be after ProcessLibraryConstructorList.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Check for Type AllocateAddress,
if NumberOfPages is 0 or
if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ADDRESS or
if (Start + NumberOfBytes) rolls over 0 or
if Start is above MAX_ADDRESS or
if End is above MAX_ADDRESS,
return EFI_NOT_FOUND.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
When the DXE core is loaded, it invokes the PeCoffExtraActionLib library
function 'PeCoffLoaderRelocateImageExtraAction' explicitly, which may be
in addition to the same function having been called by the DxeIpl PE/COFF
loader instance.
The ImageContext that DXE core presents to this function is only partially
initialized, which may result in the following output on AArch64 systems:
add-symbol-file ..MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0x5F226240
<some intermediate output>
add-symbol-file ..MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0x5F226000
This is caused by incorrect data in the ImageContext structure, which means
the start of the .text section is calculated incorrectly. In general, it is
the duty of the caller to present a valid ImageContext structure, so let's
add the missing values before invoking PeCoffLoaderRelocateImageExtraAction().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
When PcdShadowPeimOnBoot is FALSE, they are not copied to memory and
execute from their original locations. Here, this policy should only
apply for PEIM and PEI_CORE, not for other file type, such as DXE_CORE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Tested-by: Eugene Cohen <eugene@hp.com>
If 'CoreGetMemoryMap' return success the 'MemoryMap' shouldn't be NULL.
Add code to make sure this.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Yao Jiewen <Jiewen.Yao@intel.com>
According to the spec, each entry in the Memory
Attributes table shall have the same type as
the region it was carved out of in the UEFI memory map.
The current attribute uses RTData for PE Data, but
it should be RTCode.
This patch fixed the issue. It is validated with or
without PropertiesTable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
MemoryAttributesTable generation need information in
PropertiesTable.
In memory attributes table generation path,
PropertiesTable need record original memory map and do
not merge the new memory map entry cross original
memory map boundary.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Gao, Liming" <liming.gao@intel.com>
Add MemoryAttributesTable generation in DxeCore.
We leverage the information collected by original
PropertiesTable, and publish runtime code/data to
another standalone table. So that this is a
compatible solution to report more PE Code/Data
information.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Gao, Liming" <liming.gao@intel.com>
At the end of CoreFreePoolI(), the check to see if it is a specific
memory type should also cover OEM reserved memory type.
It was missed when adding OEM reserved memory type support at R17460.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
If FV image without DXE depex, it will be dispatched by DxeCore.
If FV image with SMM depex, it is the invalid image. ASSERT will be trig.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
(HandoffInformationTable->EfiFreeMemoryBottom - Private->HobList.Raw)
is the PEI temp heap used instead of the length of PEI temp heap.
The length of PEI temp heap should be:
(HandoffInformationTable->EfiFreeMemoryTop - Private->HobList.Raw)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19762 6f19259b-4bc3-4df7-8a09-765794883524
Signal a closed event will still invoke the event notification function,
it could only be exposed when no the DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED
bit set in PcdDebugPropertyMask.
For example:
gBS->CreateEvent (
EVT_NOTIFY_SIGNAL,
TPL_CALLBACK,
CallbackFun,
NULL,
&Event
);
gBS->CloseEvent (Event);
gBS->SignalEvent (Event); <- CallbackFun still be invoked
Although the case to signal a closed event is abnormal, the code could
still be enhanced to avoid it.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Thomas Palmer <thomas.palmer@hpe.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19754 6f19259b-4bc3-4df7-8a09-765794883524
The single line for(); construct is followed by code that is indented.
This triggers the -Wempty-body warning. Fix indentation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish <afish@apple.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19420 6f19259b-4bc3-4df7-8a09-765794883524
In DxeCore, use warning message for Runtime driver that doesn't satisfy
section alignment requirement. This check is required when PropertiesTable
is installed. So, add error message if PropertiesTable can't be installed
successfully.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19312 6f19259b-4bc3-4df7-8a09-765794883524
We had put communication buffer to Runtime memory,
so that SMI handler can know it is not used by OS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: "Kinney, Michael D" <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18949 6f19259b-4bc3-4df7-8a09-765794883524
PiSmmCore installs LoadedImage for each SMM driver. However itself is missing.
So we follow DxeCore style, let PiSmmCore installs LoadedImage protocol for itself,
then the SMM image information is complete.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: "Kinney, Michael D" <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18945 6f19259b-4bc3-4df7-8a09-765794883524
Original code does not uninstall LoadedImage protocol if SMM driver returns error and is unloaded.
It causes a wrong LoadedImage protocol existing in system.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: "Kinney, Michael D" <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18936 6f19259b-4bc3-4df7-8a09-765794883524
Original code refers FreePoolHdr without check Status. It is obvious wrong and has risk.
Aslo, if InternalAllocPoolByIndex() returns an error, then *FreePoolHdr is assigned to an uninitialized value. So we init Hdr be NULL.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Fan, Jeff" <jeff.fan@intel.com>
Reviewed-by: "Kinney, Michael D" <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18932 6f19259b-4bc3-4df7-8a09-765794883524
The ASSERT (PrivateData->PeiMemoryInstalled) in if (PrivateData->PeiMemoryInstalled)
condition is useless, it should be ASSERT (FALSE) to follow the code's expectation.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18887 6f19259b-4bc3-4df7-8a09-765794883524
A corner case like below will cause a NOT_DISPATCHED FV has no opportunity to
be dispatched.
1. FV_RECOVERY has SecCore, PeiCore and some other PEI modules, a module will
report FVMAIN_COMPACT and FV_RECOVERY2 in sequence.
2. FVMAIN_COMPACT has a FV image file with GUIDED FV image section in it.
3. FV_RECOVERY2 has DxeIpl and other PEI modules, the DxeIpl will install
SectionExtractionPpi
If ALL the PEIMs in FV_RECOVERY and FV_RECOVERY2 have DEPEX satisfied and
executed in one loop, PeimNeedingDispatch will be always FALSE, FVMAIN_COMPACT
will have no opportunity to be decompressed and dispatched as DxeIpl executes
after the first processing to FVMAIN_COMPACT.
The patch is to set PeimNeedingDispatch to TRUE when ProcessFvFile() not successfully,
then the NOT_DISPATCHED FV could have another opportunity to be processed.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18781 6f19259b-4bc3-4df7-8a09-765794883524
This patch fixes an issue in PEI with encapsulated FV images where the
AuthenticationStatus is not correctly propagated down to child FV
handles. The PEI core registers for callbacks for both FvInfo and
FvInfo2 PPIs. These callbacks process the FVs which will recurse as
necessary to find more encapsulated FVs. (FvInfo2 is an updated PPI
that includes an AuthenticationStatus field - the original FvInfo did
not include this.)
When encapsulated FV processing occurs the PEI core installs both
FvInfo and FvInfo2 PPIs. The original implementation installs FvInfo
first and FvInfo2 second. As soon as the FvInfo PPI is installed the
notification callback handler immediately fires causing recursive FV
processing to occur. Since there is no AuthenticationStatus provided
for the original FvInfo the callback assumes AuthenticationStatus is
zero (unsigned / unverified) even though the parent FV may have been
verified.
This changes the order of FvInfo and FvInfo2 installs to ensure that
the notification callback occurs for FvInfo2 first and appropriate
AuthenticationStatus data can be propagated from parent FV to child
FV.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18764 6f19259b-4bc3-4df7-8a09-765794883524
A subset of fields in the EFI_SMM_SYSTEM_TABLE2 structure are identical
to the fields in the SMM_ENTRY_CONTEXT structure. CopyMem() is used to
transfer the contents of the SMM_ENTRY_CONTEXT structure into the
EFI_SMM_SYSTEM_TABLE2. This is confusing because SMM_ENTRY_CONTEXT is
not used in the declaration of EFI_SMM_SYSTEM_TABLE2 and field contents
are transferred without any reference to individual field names (e.g.
CurrentlyExecutingCpu). In order to make the code easier to maintain
and understand, the CopyMem() is replaced with statements that transfer
each field of SMM_ENTRY_CONTEXT into EFI_SMM_SYSTEM_TABLE2.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Link: http://article.gmane.org/gmane.comp.bios.edk2.devel/3567
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18716 6f19259b-4bc3-4df7-8a09-765794883524
Mark the DXE stack region as non-executable right before handing
off to the DXE core, by invoking the appropriate ArmLib function.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Feng Tian <Feng.Tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18588 6f19259b-4bc3-4df7-8a09-765794883524
In a CloseEvent, an UnregisterProtocolNotify is done unconditionally.
There is a penalty associated with searching the protocol database on
every CloseEvent and impacts performance, especially during Network IO.
Unregister needs to be done only if the Event is for a RegisterProtocolNotify.
So extend the ExFlag in IEVENT to a UINT8 and define new flags that can
be set to indicate if the Event is part of a group, or registered on a
protocol notify. Then in CloseEvent, call UnregisterProtocolNotify only
if the register protocol notify flag is set.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@hpe.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18517 6f19259b-4bc3-4df7-8a09-765794883524
Take the range in the resource descriptor HOB for the memory region described
by the PHIT as higher priority if it is big enough. It can make the memory bin
allocated to be at the same memory region with PHIT that has more better compatibility
to avoid memory fragmentation for some code practices assume and allocate <4G ACPI memory.
Also let the minimal memory size needed include the total memory bin size needed to
make sure memory bin could be allocated successfully.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18503 6f19259b-4bc3-4df7-8a09-765794883524
The HOB List relocation should be at after all the tested memory resources added
(except the memory space that covers HOB List) to the memory services,
because the memory resource found in CoreInitializeMemoryServices()
may have not enough remaining resource for HOB List.
And the memory space that covers HOB List should be processed
after HOB List relocation to avoid the resources allocated by others
to corrupt HOB List before its relocation.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18499 6f19259b-4bc3-4df7-8a09-765794883524
InternalIsBufferOverlapped() is created to check overlap between buffers.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18312 6f19259b-4bc3-4df7-8a09-765794883524
in case PeiInstallPeiMemory() is done in a callback with
EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH, and the callback is registered on
a PPI that is installed in the last PEIM.
At the case, PeiCore SwitchStack code will be not being invoked.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18305 6f19259b-4bc3-4df7-8a09-765794883524
Got the build failure feedback below, this patch is to fix that.
This broke the IA32 Ovmf build for me, with GCC 5.1.1 (Fedora 22):
/home/dwmw2/git/edk2/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c:377:7:
error: ‘PageTables’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
AsmWriteCr3 (PageTables);
^
/home/dwmw2/git/edk2/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c:224:9:
note: ‘PageTables’ was declared here
UINTN PageTables;
^
cc1: all warnings being treated as errors
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18190 6f19259b-4bc3-4df7-8a09-765794883524
This feature is added for UEFI spec that says
"Stack may be marked as non-executable in identity mapped page tables".
A PCD PcdSetNxForStack is added to turn on/off this feature, and it is
FALSE by default.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: "Yao, Jiewen" <Jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18166 6f19259b-4bc3-4df7-8a09-765794883524
to right after CoreInitializeGcdServices().
Why?
Some platforms maybe report both below 4G and above 4G memory resource hob as tested,
then CoreInitializeMemoryServices() will find and add the tested above 4G memory resource hob to memory descriptor for early memory allocation services,
then if ProcessLibraryConstructorList() that has library constructor tries to allocate below 4G memory and will fail.
In fact, the following CoreInitializeGcdServices() will add all the memory resource hob to GCD map,
and add the tested below 4G memory resource hob to memory descriptor,
but it has been too late for ProcessLibraryConstructorList().
Also move below two lines as they are needed to be after
the constructor of DxeCorePerfomanceLib.
PERF_END (NULL,"PEI", NULL, 0) ;
PERF_START (NULL,"DXE", NULL, 0) ;
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18146 6f19259b-4bc3-4df7-8a09-765794883524
v2 changelog:
Check CurrentPeimHandle to check the matched PeimHandle.
Add check point to ShadowPeiCore based on PCD.
v1 changelog:
PeiCore LoadImage always shadow itself and PEIM on normal boot after
the physical memory is installed. On the emulator platform, the shadow
may be not necessary. To support such usage, new PCD PcdShadowPeimOnBoot
is introduced to specify whether loads PEIM in memory by default.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18125 6f19259b-4bc3-4df7-8a09-765794883524
to instead of AllocatePool() to ensure the data is clean for
the following consumption.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18087 6f19259b-4bc3-4df7-8a09-765794883524
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 <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18031 6f19259b-4bc3-4df7-8a09-765794883524
Ard Biesheuvel
Star Zeng
Liming Gao
Ruiyu Ni
Qiu Shumin
Jiewen Yao
Cinnamon Shia
Hao Wu
Andrew Fish
Jordan Justen
Eugene Cohen
Michael Kinney
Samer El-Haj-Mahmoud
Laszlo Ersek