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
Add the check at DxeLoadCore() on MdeModulePkg\Core\DxeIplPeim\DxeLoad.c
to skip install the "gEfiMemoryTypeInformationGuid" hob if it is already
installed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18018 6f19259b-4bc3-4df7-8a09-765794883524
GCD Range is byte address. EFI memory range is page address. To make sure
GCD range is converted to EFI memory range, the following things are added:
1. Merge adjacent GCD range first.
2. Add ASSERT check on GCD range alignment.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17813 6f19259b-4bc3-4df7-8a09-765794883524
The splitting of memory regions into code and data regions violates
architecture specific alignment rules by using a fixed alignment
of 4 KB. Replace it with EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT,
which is defined appropriately on each architecture.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Jaben Carsey" <jaben.carsey@intel.com>
Reviewed-by: "Yao, Jiewen" <Jiewen.Yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17812 6f19259b-4bc3-4df7-8a09-765794883524
Move the definitions of EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT and
DEFAULT_PAGE_ALLOCATION to DxeMain.h to make them available explicitly
to all parts of DxeCore.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Yao, Jiewen" <Jiewen.Yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17811 6f19259b-4bc3-4df7-8a09-765794883524
This removes the functions RevertRuntimeMemoryMap () and
DumpMemoryMap () which are not referenced anywhere in the code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Yao, Jiewen" <Jiewen.Yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17808 6f19259b-4bc3-4df7-8a09-765794883524
UEFI Spec HTTP Boot Device Path, after retrieving the boot resource
information, the BootURI device path node will be updated to include
the BootURI information. It means the device path on the child handle
will be updated after the LoadFile() service is called.
To handle this case, DxeCore LoadImage() service is updated as the below:
1) Get Device handle based on Device Path
2) Call LoadFile() service (GetFileBufferByFilePath() API) to get Load File Buffer.
3) Retrieve DevicePath from Device handle
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17799 6f19259b-4bc3-4df7-8a09-765794883524
Child FV may be placed in parent FV image without process required. Then,
Child FV and parent FV will be in the same continuous space. For FileHandle,
FileHandleToVolume() function needs to find the best matched FV handle.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17704 6f19259b-4bc3-4df7-8a09-765794883524
UEFI2.5 spec, GetMemoryMap(), says:
Attribute: Attributes of the memory region that describe the bit mask
of capabilities for that memory region, and not necessarily the current
settings for that memory region.
But, GetMemoryMap() implementation doesn't append memory capabilities
for MMIO and Reserved memory range. This will break UEFI2.5 Properties
Table feature, because Properties Table need return EFI_MEMORY_RO or
EFI_MEMORY_XP capabilities for OS.
This patch appends memory capabilities for those memory range.
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@17703 6f19259b-4bc3-4df7-8a09-765794883524
And also SMM Ready To Boot.
The SMM Exit Boot Service protocol is to be published by the SMM
Foundation code to associate with EFI_EVENT_GROUP_EXIT_BOOT_SERVICES
to notify SMM driver that system enter exit boot services.
The SMM Legacy Boot protocol is to be published by the SMM
Foundation code to associate with EFI_EVENT_LEGACY_BOOT_GUID
to notify SMM driver that system enter legacy boot.
The SMM Ready To Boot protocol is to be published by the SMM
Foundation code to associate with EFI_EVENT_GROUP_READY_TO_BOOT
to notify SMM driver that system enter ready to boot.
After them, any SMM drivers can get protocol notify on what happened
in DXE phase, then there is no need to let each individual SMM driver
to register SMM Communication Handler for that.
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@17657 6f19259b-4bc3-4df7-8a09-765794883524
The correct logic should be:
- The SectionAlignment is got from Magic number.
- The Magic number is got from PE header and machine type.
The original code mix them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <Jiewen.yao@intel.com>
Reviewed-by: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17603 6f19259b-4bc3-4df7-8a09-765794883524
1. In PiSmmIpl.c, free FullSmramRanges at error condition.
2. Move pool and page management definitions and structures
from PiSmmCorePrivateData.h to PiSmmCore.h.
PiSmmCorePrivateData.h should be only used to share SMM_CORE_PRIVATE_DATA
between PiSmmCore and PiSmmIpl. Pool and page management definitions
and structures were moved from Pool.c and Page.c to PiSmmCorePrivateData.h
incorrectly for memory profile feature at EDK2 R16335 commit.
3. DumpSmramInfo() only used for memory profile, so move the declaration
into SmramProfileRecord.c.
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@17598 6f19259b-4bc3-4df7-8a09-765794883524
Use if (Image->Started) condition judgement before call to
UnregisterMemoryProfileImage() in CoreUnloadAndCloseImage().
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@17597 6f19259b-4bc3-4df7-8a09-765794883524
DescEnd will be clipped for alignment in CoreFindFreePagesI, and it
may fall below DescStart, when alignment is more than 16KB (included)
and both DescStart and original DescEnd fall into a single range of
such alignment. This results in a huge size (Negative number in
unsigned type) for this descriptor, fulfilling the allocation
requirement but failing to run ConvertPages; at last it causes
occasional failure of AllocatePages.
A simple comparison is added to ensure we would never get a negative
number.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17575 6f19259b-4bc3-4df7-8a09-765794883524
The debug message is to print the current TPL and requested TPL value.
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@17543 6f19259b-4bc3-4df7-8a09-765794883524
ARM toolchain raises the build error: "enumerated type mixed with
another type".
To fix the issue, typecase can be used like below.
- return EfiMaxMemoryType + 1;
+ return (EFI_MEMORY_TYPE)(EfiMaxMemoryType + 1);
But to eliminate the confusion, update the return type of
GetProfileMemoryIndex() from EFI_MEMORY_TYPE to UINTN.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17535 6f19259b-4bc3-4df7-8a09-765794883524
This change will make DEBUG information be aligned with DEBUG_GCD enabled.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17470 6f19259b-4bc3-4df7-8a09-765794883524
When the ExecuteSmmCoreFromSmram() function fails, SmmIplEntry()
restores the SMRAM range to EFI_MEMORY_UC. However, it saves the
return value of gDS->SetMemorySpaceAttributes() in the same Status
variable that gDS->contains the return value of ExecuteSmmCoreFromSmram().
Therefore, if gDS->SetMemorySpaceAttributes() succeeds, the failure
of ExecuteSmmCoreFromSmram() is masked, and Bad Things Happen (TM).
Introduce a temporary variable just for the return value of
gDS->SetMemorySpaceAttributes().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17417 6f19259b-4bc3-4df7-8a09-765794883524
Yao, Jiewen
Zeng, Star
Eugene Cohen
Michael Kinney
Ard Biesheuvel
Samer El-Haj-Mahmoud
Laszlo Ersek
Liming Gao
Qiu Shumin
Heyi Guo
Zachary Bobroff