BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3223
In the current design, memory protection is not available till CpuDxe
is loaded. To resolve this, introduce CpuArchLib to move the
CPU Architectural initialization to DxeCore.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Handle.c:1302:24: error: 'Prot' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
*Interface = Prot->Interface;
~~~~^~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Add a late initialize in DxeMain for the debug agent. This is required
for the debug agent to be able to setup events to handle image loads,
exit boot services, and other important callbacks.
Define a reinitialize debug agent.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
According to UEFI spec 2.10 errata A section 7.4.6
"All events from the EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES and
EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event notification groups as well
as events of type EVT_SIGNAL_EXIT_BOOT_SERVICES must be signaled
before ExitBootServices() returns EFI_SUCCESS. The events are only
signaled once even if ExitBootServices() is called multiple times."
So keep track of whether ExitBootServices() has been called, and signal
the event group EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES only the first
time around.
EFI_EVENT_GROUP_EXIT_BOOT_SERVICES will only be signalled if
ExitBootServices() is going to run to [successful] completion, after
which calling it a second time is not possible anyway. So for this case,
no special handling is needed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Check that the next map entry is valid before dereferencing to merge the
guard pages. If the final entry is at the end of a page with no valid page
following it, then this can cause an access violation.
Signed-off-by: Kenneth Lautner <kenlautner3@gmail.com>
Comments out a redundant call to RestoreTpl(). While this does not
technically violate spec on raise/restore TPL, TPL should already be at
the specified level. This extra call introduces an asymmetry between
RaiseTpl and RestoreTpl calls, which makes analysis of TPL correctness
more difficult and hampers certain non-standard TPL usages that some
platforms require. Additionally, the two TPL variables were renamed to
provide context for each of them.
Signed-off-by: Kenneth Lautner <kenlautner3@gmail.com>
REF : https://bugzilla.tianocore.org/show_bug.cgi?id=4817
Before entering BIOS setup, CoreValidateHandle function executed
over 600,000 times during BDS phase on latest 8S server platform.
In CoreValidateHandle function, current implementation will go
through the doubly-linked list handle database in each call, and
this will have big impact on boot performance.
The optimization is using Red-black tree to store the EFI handle
address when insert each EFI handle into the handle database, and
remove the handle from Red-black tree if the handle is removed
from the handle database. CoreValidateHandle function changed to
go through the Red-black tree.
After verification on latest 8S server platform, BDS boot time can
save 20s+ after this change.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Andrew Fish <afish@apple.com>
Tested-by: Xiaoqiang Zhang <xiaoqiang.zhang@intel.com>
Currently whenever gDS->SetMemorySpaceCapabilities() is called, it
attempts to set the corresponding attributes in the gMemoryMap
descriptor. However, gMemoryMap only contains entries from GCD types
EfiGcdMemoryTypeSystemMemory and EfiGcdMemoryTypeMoreReliable, so
for all other types a failure is reported in the code. This is a
failure that is expected, so it does not provide value and can
lead to real failures being ignored.
This patch updates the gDS->SetMemorySpaceCapabilities() code to
only call into updating gMemoryMap if the GCD type is SystemMemory
or MoreReliable, to avoid spurious errors being reported. This
also avoids the expensive operation of searching through gMemoryMap
for entries we know we will fail to find.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
