CoreLocateDevicePath is used in CoreInstallMultipleProtocolInterfaces to
check if a Device Path Protocol instance with the same device path is
alreay installed.
CoreLocateDevicePath is a generic API, and would introduce some
unnecessary overhead for such usage.
The optimization is:
1. Implement IsDevicePathInstalled to loop all the Device Path
Protocols installed and check if any of them matchs the given device
path.
2. Replace CoreLocateDevicePath with IsDevicePathInstalled in
CoreInstallMultipleProtocolInterfaces.
This optimization could save several seconds in PCI enumeration on a
system with many PCI devices.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhi Jin <zhi.jin@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Ancient GCC 4.8.5 warned about variable may be unitialied.
And it doesn't look like false alarm.
The warning is:
edk2/RedfishPkg/Library/HiiUtilityLib/HiiUtilityInternal.c: In function 'GetQuestionDefault':
edk2/RedfishPkg/Library/HiiUtilityLib/HiiUtilityInternal.c:5519:6: error: 'ConfigAccess' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (ConfigAccess != NULL) {
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
AndroidBootImgLib allows for platforms to append to kernel command
line but does not allow for the overall kernel command line to go
beyond the limit set by the image header. Address this limitation
by adding a pcd where platform can tell how many extra characters
they expect on their platform in addition to what the image header
specifies.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Curently, AndroidBootImgLib expects input kernel command line
to never exceed 256 unicode characters where the image header
allows for 512 ascii characters. If image header allows 512
ascii characters, similar number of unicode characters should be
allowed at the minimum.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Currently, if BSP election is not enabled, will use Core0 as SMM BSP.
However, Core0 does not always have the highest performance.
So, we can used NonSmm BSP as default BSP.
This will take effect in normal SMM init flow and S3 boot flow.
In normal SMM flow, the code is executed before first SMI.
In S3 flow, the code is executed in Non-SMM BSP's first SMI, where the
gSmmCpuPrivate keeps the data from last boot.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4597
When creating a new variable, skip marking VAR_HEADER_VALID_ONLY so that
variable header + data update can be merged into one flash write. This
will greatly reduce the time taken for updating a variable and thus
increase performance. Removing VAR_HEADER_VALID_ONLY marking doesn't
have any function impact since it's not used by current code to detect
variable header + data corruption.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Gao Cheng <gao.cheng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
If the SetVirtualAddressMap() is not called, mIsVirtualAddrConverted
is FALSE and the kernel crash occurs in IsNestedFmpCapsule() when
executing gBS->LocateProtocol () in the else case.
To serve the omitted SetVirtualAddressMap() call, we could just check
mEsrtTable presence instead of relying on mIsVirtualAddrConverted.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
GetNextEntryAttribute() is currently applying a 64-bit mask
(TT_ATTRIBUTES_MASK) to a 32-bit descriptor value (EntryType).
The original descriptor was 64 bits containing the upper and
lower attributes which are included in TT_ATTRIBUTES_MASK.
The PrevEntryAttribute parameter is also a UINT32, but passed to
PageAttributeToGcdAttribute() for a UINT64 parameter where the
function checks masks in the upper 32 bits of the integer value:
PageAttributeToGcdAttribute (*PrevEntryAttribute)
...
STATIC
UINT64
PageAttributeToGcdAttribute (
IN UINT64 PageAttributes
)
...
if ((PageAttributes & (TT_PXN_MASK | TT_UXN_MASK)) != 0) {
GcdAttributes |= EFI_MEMORY_XP;
}
...
#define TT_PXN_MASK BIT53
#define TT_UXN_MASK BIT54 // EL1&0
This change removes UINT32 intermediary values. For EntryType,
eliminating an unncessary cast. For EntryAttribute, preserving the
upper and lower attributes for evaluation in
PageAttributeToGcdAttribute().
This also resolves the following compiler warning previously present
on Visual Studio for the assignment to the previously 32-bit local
variables.
'=': conversion from 'UINT64' to 'UINT32', possible loss of data
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In order to allow the VMM (such as QEMU) to add a page with hashes of
kernel/initrd/cmdline for measured direct boot on SNP, add it explicitly
to the SNP metadata list report to the VMM.
In such case, VMM should fill the page with the hashes content, or
explicitly update it as a zero page (if kernel hashes are not used).
Note that for SNP, the launch secret part of the page (lower 3KB) are
not relevant and will remain zero. The last 1KB is used for the hashes.
This should have no effect on OvmfPkgX64 targets (which don't define
PcdSevLaunchSecretBase).
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Resize the MEMFD section of AmdSevX64.fdf and reorder its pages so that
it matches the same size and order used in OvmfPkgX64.fdf.
After this change, this is the difference in the MEMFD of the two
targets:
$ diff -u \
<(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/OvmfPkgX64.fdf) \
<(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/AmdSev/AmdSevX64.fdf)
--- /dev/fd/63 2023-02-16 07:06:15.365308683 +0000
+++ /dev/fd/62 2023-02-16 07:06:15.365308683 +0000
@@ -32,6 +32,12 @@
0x00E000|0x001000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
+0x00F000|0x000C00
+gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
+
+0x00FC00|0x000400
+gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
+
0x010000|0x010000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
With SEV-SNP, the SEV-ES save area for a vCPU should be unique to that
vCPU. After commit 3323359a81, the VMSA allocation was re-used, but when
sorting the CPUs by APIC ID, the save area was not updated to follow the
original CPU. Similar to the StartupApSignal address, the SevEsSaveArea
address should be updated when sorting the CPUs.
This does not cause an issue at this time because all APs are in HLT state
and then are (re)started at the same time, with the same VMSA contents.
However, this should be fixed to account for any change in future
behavior.
Fixes: 3323359a81 ("UefiCpuPkg/MpInitLib: Reuse VMSA allocation to ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input when
returning CPUID information. However, the AsmCpuid() function does not
zero out ECX before the CPUID instruction, so the input leaf is used as
the sub-leaf for the CPUID request and returns erroneous/invalid CPUID
data, since the intent of the request was to get data related to sub-leaf
0. Instead, use AsmCpuidEx() for the CPUID_EXTENDED_TOPOLOGY leaf.
Fixes: d4d7c9ad5f ("UefiCpuPkg/MpInitLib: use BSP to do extended ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
mReplaceLiveEntryFunc is a function pointer but assigned as a VOID*
pointer:
mReplaceLiveEntryFunc = *(VOID **)GET_GUID_HOB_DATA (Hob);
This leads to the Visual Studio warning:
nonstandard extension, function/data pointer conversion in
expression
This change updates the assignment to avoid using a data pointer and
defines a type for the function pointer to succinctly and accurately
refer to the type when it is used in the library code.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
PiSmmCore fetches the EFI memory map and calls SplitTable() to
split each loaded image section into its own descriptor with
EFI_MEMORY_XP marking data sections and EFI_MEMORY_RO marking
code sections.
The SMM MAT logic is almost identical to the DXE MAT logic but goes
a step further and also updates the memory map descriptors which describe
image code and data sections to be of type EfiRuntimeServicesCode and
EfiRuntimeServicesData respectively. The consolidated MAT logic
(present in the new ImagePropertiesRecordLib) more closely follows
the DXE MAT logic which identifies image code sections by the presence
of the attribute EFI_MEMORY_RO in the descriptor and image data
sections by the presence of the attribute EFI_MEMORY_XP. Because of
the flow choice of the consolidated MAT logic, the SMM MAT logic should
just use the attributes from the table returned by SplitTable().
Additionally, the function EnforceMemoryMapAttribute() in the SMM MAT
logic will ensure that the CODE and DATA memory types have the desired
attributes so bisecting this patch series at this commit will still
function as before.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Update function headers to clarify the contract of each function and
improve readability. Add NULL checks to all functions that take a
pointer as an argument. Add return status to functions that
may need to return early due to invalid input.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
SplitRecord() does not handle the case where a memory descriptor
describes an image region plus extra pages before or after the
image region. This patch fixes this case by carving off the
unrelated regions into their own descriptors.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|4K PAGE|DATA|CODE|DATA|CODE|DATA|4K PAGE|
Say the above memory region is currently one memory map descriptor.
The above image memory layout example contains two code sections
oriented in a way that maximizes the number of descriptors which
would be required to describe each section.
NOTE: It's unlikely that a data section would ever be between
two code sections, but it's still handled by the below formula
for correctness.
There are two code sections (let's say CodeSegmentMax == 2),
three data sections, and two unrelated memory regions flanking the
image. The number of required descriptors to describe this layout
will be 2 * 2 + 3 == 7. This patch updates the calculations to account
for the worst-case scenario.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Create a host-based unit test for the ImagePropertiesRecordLib
SplitTable() logic. This test has 4 cases which tests different
potential image and memory map layouts. 3/4 of these tests fail
with the logic in its current state to provide proof of the bugs
in the current MAT logic.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
No functional changes in this patch.
Updates the comments of _CPU_MP_DATA to delcared that duplications in
CpuMpData are present to avoid to be direct accessed and comprehended
in assembly code. CpuMpData: Intended for use in C code while
ExchangeInfo are used in assembly code in this module.
This patch deletes the unnecessary comments in CpuMpData, since
CpuMpData is no longer responsible for passing information from PEI to
DXE.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Laszlo Ersek lersek@redhat.com
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
This patch synchronizes the No-Execute bit in the IA32_EFER
register for the APs before the RestoreVolatileRegisters operation.
The commit 964a4f0, titled "Eliminate the second INIT-SIPI-SIPI
sequence," replaces the second INIT-SIPI-SIPI sequence with the BSP
calling the SwitchApContext function to initiate a specialized start-up
signal, waking up APs in the DXE instead of using INIT-SIPI-SIPI.
Due to this change, the logic for "Enable execute disable bit" in
MpFuncs.nasm is no longer executed. However, to ensure the proper setup
of the page table, it is necessary to synchronize the IA32_EFER.NXE for
APs before executing RestoreVolatileRegisters .
Based on SDM:
If IA32_EFER.NXE is set to 1, it signifies execute-disable, meaning
instruction fetches are not allowed from the 4-KByte page controlled by
this entry. Conversely, if it is set to 0, it is reserved.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek lersek@redhat.com
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
