Due to PEIM will do following MM notify event under API mode:
1.MM end of dxe notify Event
2.MM ready to lock notify Event
3.MM ready to boot notify Event
4.MM exit boot services notify Event
It will conflict with the notify event in MmCommunicationDxe.inf
on edk2 bootloader under API mode, so split following MmEvent to
MmCommunicationNotifyDxe.inf, and avoid run this driver under API
mode.
Signed-off-by: Hongbin1 Zhang <hongbin1.zhang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Dun Tan <dun.tan@intel.com>
Cc: Khor Swee Aun <swee.aun.khor@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
In the MpInitLib, pages are allocated for
the APs, and data is copied into them. Depending
on the allocation type, Nx needs to be removed
from the pages to allow the processors to execute.
Additionally, ReadOnly needs to be applied to the
pages after they have been filled with the
instructions that the APs need to execute.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Co-authored-by: Oliver Smith-Denny <osde@microsoft.com>
Update the comments for PcdDxeNxMemoryProtectionPolicy
which contained old information.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Co-authored-by: Oliver Smith-Denny <osde@microsoft.com>
Currently, if the DebugClearMemory bit is set in the
PcdDebugPropertyMask, CoreConvertPagesEx will attempt to write
a pattern to the pages being freed. However, it does not check
that the page is writeable, which will cause a page fault if not.
Furthermore, if NX protections are not enabled, the core does not
ensure that any freed pages are RW, which is the state expected
when they are allocated next. If they are not RW, the allocating
driver will crash trying to use them.
This patch updates the page freeing code to query the memory
attributes protocol, if present, for the attributes. If this call
fails or the attributes are not RW at a minimum, the core leaks
the memory (returning success to the caller). If the memory
attribute protocol is not present (either because a platform doesn't
produce it or it is before the protocol has been produced, the core
continues with freeing memory. This is either before the CPU Arch
protocol is available (so drivers can't change memory attributes) or
otherwise matches existing behavior. This was deemed the best
approach to let memory that can't be guaranteed to be RW leak
instead of letting a driver crash when allocating it. It was deemed
less brittle to simply leak the memory instead of attempting to
change the attributes.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
These libraries required dependency on EmbeddedPkg for the
FdtHob which has been moved to MdePkg. This dependency is not
needed anymore and can now be removed.
Signed-off-by: Akshay Behl <cap2k4@rivosinc.com>
Co-authored-by: Dhaval Sharma <dhaval@rivosinc.com>
There is GetPerformanceCounterProperties() that relies
on Device Tree to fetch timer frequency and removes the
dependency from the PCDs, use that instead.
Signed-off-by: Akshay Behl <cap2k4@rivosinc.com>
Co-authored-by: Dhaval Sharma <dhaval@rivosinc.com>
There is GetPerformanceCounterProperties() that relies
on Device Tree to fetch timer frequency and removes the
dependency from the PCDs, use that instead.
Signed-off-by: Akshay Behl <cap2k4@rivosinc.com>
Co-authored-by: Dhaval Sharma <dhaval@rivosinc.com>
MdePkg has a more refined implementation of Fdt as compared
to the EmbeddedPkg which was the initial implementation, hence
moving the Fdt Guid from EmbeddedPkg to MdePkg.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Akshay Behl <cap2k4@rivosinc.com>
Co-authored-by: Dhaval Sharma <dhaval@rivosinc.com>
On RISC-V platforms, just like other platforms, we need to pass various
information from one stage to another (hartid/cmo operations etc).
Also there are some settings like Timer freq which are platform dependent
which use PCDs. Today hartid is extracted through Firmware Context
(custom in mem structure passed from one stage to another). For CMO we
have a features HOB. Going forward we would like to have a standard
mechanism to pass on such information and DT is handy as it can easily
carry all this information (in some cases nodes already exists). This
patch implement timebase frequency extraction from DT.
Signed-off-by: Akshay Behl <cap2k4@rivosinc.com>
Co-authored-by: Dhaval Sharma <dhaval@rivosinc.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
If a memory debug log buffer is present, register the buffer location as
config table so the OS can find and show it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
PrePiMemoryAllocationLib does not implement functions to allocate
EfiMemoryReservedType. These are implemented in other instances of
MemoryAllocationLib (Dxe, Uefi, PiSmmCore, SmmMemory).
Add AllocateReservedPages() and AllocateAlignedReservedPages()
functions to make it consistent with other MemoryAllocationLib
intstances.
Signed-off-by: Vishal Oliyil Kunnil <vishalo@qti.qualcomm.com>
This check is present for every call to `MemDebugLogWrite` but it is
missing here. This may cause an unwanted write to the
buffer, when the buffer's address is not null and MemDebug is disabled.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
Allow PR eval to operate with the same input variable values as the
build command would.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Currently DxeIpl attempts to set page 0 to all 0's and to
create a memory allocation HOB for it. However, DxeIpl will
also unmap the page when mapping page tables and if null
detection is not enabled, DxeCore will set the page to 0,
regardless of allocation status.
Because no consumers are using the memory allocation HOB for
page 0, drop it. Instead, ensure that PeiCore and DxeCore do
not allow allocating page 0; it should always be reserved for
null pointer detection. It also complicates the story for
platforms that are attempting to audit the system and ensure that
no modules are using page 0. With these memory allocation HOBs
in place, it is difficult to tell if it is simply DxeIpl who
has allocated the memory or another module.
This commit drops the memory allocation HOB publishing and ensures
that DxeCore and PeiCore do not allocate page 0. DxeCore already
will not allocate page 0 to callers of AllocatePages who call with
a type other than AllocateAddress, this just changes so that
AllocateAddress cannot allocate at page 0 (which if null detection
is enabled will cause a page fault). PeiCore does not have
AllocateAddress and so this ensures standard allocations do not
receive page 0.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
OvmfPkg has copied the MdeModulePkg DxeIpl behavior to
create a memory allocation HOB for page 0. That is being changed
(see that commit for details), so also remove it here.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
UefiPayloadPkg has copied the MdeModulePkg DxeIpl behavior to
create a memory allocation HOB for page 0. That is being changed
(see that commit for details), so also remove it here.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Build report would not detect a nested FV if the nested
FV was not in a subsection of an FFS statement.
Modify the build report to better handle some of the
variations of nested FVs.
Failing Example:
[Fv.FvName1]
INF <path to some driver>.inf
[Fv.FvName0]
FILE FV_IMAGE = B25ACDEF-39CE-4FA5-B50A-33E24DB1BDDF {
SECTION FV_IMAGE = FvName1
}
Working Example:
[Fv.FvName1]
INF <path to some driver>.inf
[Fv.FvName0]
FILE FV_IMAGE = DA04F6BF-A0FD-47EC-928B-5101A6C95026 {
SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF
PROCESSING_REQUIRED = TRUE {
SECTION FV_IMAGE = FvName1
}
}
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Add QEMU_PV_VARS build option, when enables the firmware build will
support (and require) the qemu uefi variable store.
This also enables proper (as-in: actually being secure) secure boot
support.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
32-bit architecture (ia32 + arm) are not supported. Update inf file
accordingly. Add a VALID_ARCHITECTURES line. Drop ARM configuration.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Introduce AArch64 architecture support in BlSupportDxe. Translation
table would be created based on the memory maps, which is provided
by bootloader, in case MMU is disabled when execution is handed
over to Universal Payload.
Signed-off-by: Ajan Zhong <ajan.zhong@newfw.com>
Move ArmMmuLib from ArmPkg to UefiCpuPkg for easy maintaining.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ajan Zhong <ajan.zhong@newfw.com>
Since ArmMmuLib.h has been moved to UefiCpuPkg, add corresponding dec
file to AcceptableDependencies to ArmPkg, ArmPlatformPkg and ArmVirtPkg.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ajan Zhong <ajan.zhong@newfw.com>
Move the ArmMmuLib interface definition to UefiCpuPkg, with this change,
MMU libraries for ARM, AARCH64, RiscV, LongArch64 architectures all
reside in UefiCpuPkg.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ajan Zhong <ajan.zhong@newfw.com>
