The top two bits of the Extended BIOS ROM Size field indicates the unit
used for the remaining 14 bits. If the size is greater than 16GB, the
unit is gigabytes.
The test for this uses the local BiosPhysicalSize variable, which is a
UINTN, meaning that when building for ARM/CLANGDWARF we have a
tautological constant comparison, which the toolchain flags now we've
stopped disabling that warning.
So switch the BiosPhysicalSize variable to UINT64.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Fix smm perf issue in DxeCorePerformanceLib. In
current code logic, total SMM perf record is copied
multiple times to FPDT table if multiple ReadyToBoot
events are signaled. This patch changes the function
InternalGetSmmPerfData() to only get newly generated
Smm perf data. Then previous generated Smm perf data
won't be copied to FPDT again.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4470
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This updates the system slot ID up to SlotTypePCIExpressGen6andBeyond
(0xC4) added by updating type 9 with SMBIOS version 3.5 to cover modern
PCIe Gens.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
A faulty PCI device has the Option ROM image size set to 0. UEFI reads
two headers PCI_EXPANSION_ROM_HEADER and PCI_DATA_STRUCTURE to get the
Option ROM information. Because the image size is 0, the Option ROM
header address never changes. As a result, UEFI keeps reading the same
two headers definitely. This patch is intended to fix it.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The global variable has a common name that can conflict with other
TCG modules. For example, Tcg2Dxe has a similarly named global that
is of type EFI_TCG2_PROTOCOL instead of EFI_TCG2_PROTOCOL*.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The block size configuration of Blockmap does not match that in Qemu
VirtNorFlash, which causes variable data to be written into FtwWorkBlock
by mistake, resulting in data loss during reboot. Fix it and update
new checksum value.
Signed-off-by: Qingyu Shang <2931013282@sjtu.edu.cn>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Currently, HeapGuard, when in the GuardAlignedToTail mode, assumes that
the pool head has been allocated in the first page of memory that was
allocated. This is not the case for ARM64 platforms when allocating
runtime pools, as RUNTIME_PAGE_ALLOCATION_GRANULARITY is 64k, unlike
X64, which has RUNTIME_PAGE_ALLOCATION_GRANULARITY as 4k.
When a runtime pool is allocated on ARM64, the minimum number of pages
allocated is 16, to match the runtime granularity. When a small pool is
allocated and GuardAlignedToTail is true, HeapGuard instructs the pool
head to be placed as (MemoryAllocated + EFI_PAGES_TO_SIZE(Number of Pages)
- SizeRequiredForPool).
This gives this scenario:
|Head Guard|Large Free Number of Pages|PoolHead|TailGuard|
When this pool goes to be freed, HeapGuard instructs the pool code to
free from (PoolHead & ~EFI_PAGE_MASK). However, this assumes that the
PoolHead is in the first page allocated, which as shown above is not true
in this case. For the 4k granularity case (i.e. where the correct number of
pages are allocated for this pool), this logic does work.
In this failing case, HeapGuard then instructs the pool code to free 16
(or more depending) pages from the page the pool head was allocated on,
which as seen above means we overrun the pool and attempt to free memory
far past the pool. We end up running into the tail guard and getting an
access flag fault.
This causes ArmVirtQemu to fail to boot with an access flag fault when
GuardAlignedToTail is set to true (and pool guard enabled for runtime
memory). It should also cause all ARM64 platforms to fail in this
configuration, for exactly the same reason, as this is core code making
the assumption.
This patch removes HeapGuard's assumption that the pool head is allocated
on the first page and instead undoes the same logic that HeapGuard did
when allocating the pool head in the first place.
With this patch in place, ArmVirtQemu boots with GuardAlignedToTail
set to true (and when it is false, also).
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4521
Github PR: https://github.com/tianocore/edk2/pull/4731
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
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: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Copy the function BuildPlatformInfoHob() from OvmfPkg/PlatformPei.
QemuFwCfgLib expect this HOB to be present, or fails to do anything.
InternalQemuFwCfgIsAvailable() from QemuFwCfgPeiLib module will not
check if the HOB is actually present for example and try to use a NULL
pointer.
Fixes: cda98df162 ("OvmfPkg/QemuFwCfgLib: remove mQemuFwCfgSupported + mQemuFwCfgDmaSupported")
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The implementation of this new behavior aligns with the guidelines
outlined in the Intel SDM.
Following a power-up or RESET of an MP system, system hardware
dynamically selects one of the processors on the system bus as the BSP.
The remaining processors are designated as APs. The APs complete a
minimal self-configuration, then wait for a startup signal (a SIPI
message) from the BSP processor.
Additionally, the MP protocol is executed only after
a power-up or RESET. If the MP protocol has completed and a
BSP is chosen, subsequent INITs (either to a specific processor or
system wide) do not cause the MP protocol to be repeated. Instead, each
logical processor examines its BSP flag (in the IA32_APIC_BASE MSR) to
determine whether it should execute the BIOS boot-strap code (if it is
the BSP) or enter a wait-for-SIPI state (if it is an AP).
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>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Rewrite the script to configure openssl 3.0 from scratch. It's two
scripts now:
* Tiny helper script, dumping the perl configdata as json.
* Actual configure.py script, written in python, which copies over
the generated files to openssl-gen and updates the OpensslLib*.inf
file lists and build flags.
The configuration workflow has changed a bit:
* All generated files are stored in the OpensslGen directory tree.
* For ec/no-ec builds two different header files are used. Default is
the ec variant, and the new EDK2_OPENSSL_NOEC define is used to
select the no-ec build. A five line wrapper include is used to pick
the one or the other.
* For non-accel builds -DOPENSSL_NO_ASM on the command line is used
(same as before).
* For configration defines the OPENSSL_FLAGS_$(variant) variable is
used, where variant is the architecture for the accelerated builds
and 'NOASM' for the non-accelerated builds.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Yi Li <yi1.li@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Brian J. Johnson <brian.johnson@hpe.com>
Tested-by: Kenneth Lautner <klautner@microsoft.com>
