Sync with edk2 oct 2023 v2 #87
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 <[email protected]> Cc: Ray Ni <[email protected]> Cc: Rahul Kumar <[email protected]> Cc: Gerd Hoffmann <[email protected]> Signed-off-by: Ray Ni <[email protected]> Signed-off-by: Yuanhao Xie <[email protected]> Reviewed-by: Ray Ni <[email protected]>
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: cda98df ("OvmfPkg/QemuFwCfgLib: remove mQemuFwCfgSupported + mQemuFwCfgDmaSupported") Signed-off-by: Corvin Köhne <[email protected]> Reviewed-by: Rebecca Cran <[email protected]>
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: tianocore/edk2#4731 Cc: Leif Lindholm <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Jian J Wang <[email protected]> Cc: Liming Gao <[email protected]> Cc: Dandan Bi <[email protected]> Signed-off-by: Oliver Smith-Denny <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Acked-by: Leif Lindholm <[email protected]> Reviewed-by: Liming Gao <[email protected]>
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 <[email protected]> Reviewed-by: Sunil V L <[email protected]>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4532 To Copy the PrebuildUplBinary to Build folder then add/replace Fvs. Cc: Guo Dong <[email protected]> Cc: Ray Ni <[email protected]> Reviewed-by: James Lu <[email protected]> Reviewed-by: Gua Guo <[email protected]> Signed-off-by: KasimX Liu <[email protected]>
https://bugzilla.tianocore.org/show_bug.cgi?id=4502 Update SplitFspBin.py to support child FV in FSP binary. Without the patch, the tool won't be able to rebase the images in child FV in FSP binary. Cc: Chasel Chiu <[email protected]> Cc: Nate DeSimone <[email protected]> Cc: Star Zeng <[email protected]> Cc: Ashraf Ali S <[email protected]> Cc: Chinni B Duggapu <[email protected]> Cc: Ray Han Lim Ng <[email protected]> Cc: Susovan Mohapatra <[email protected]> Signed-off-by: Ted Kuo <[email protected]> Reviewed-by: Chasel Chiu <[email protected]>
FSP-SMM module need get and set FspSmmInit upd data pointer functions to get and set upd settings. Signed-off-by: Hongbin1 Zhang <[email protected]> Cc: Chasel Chiu <[email protected]> Cc: Nate DeSimone <[email protected]> Cc: Duggapu Chinni B <[email protected]> Cc: Ray Han Lim Ng <[email protected]> Cc: Star Zeng <[email protected]> Cc: Ted Kuo <[email protected]> Cc: Ashraf Ali S <[email protected]> Cc: Susovan Mohapatra <[email protected]> Reviewed-by: S Ashraf Ali <[email protected]> Reviewed-by: Chasel Chiu <[email protected]>
This fixes an unused variable 'Index' error in release build. Signed-off-by: Nhi Pham <[email protected]> Reviewed-by: Abner Chang <[email protected]>
Disable PcdFirstTimeWakeUpAPsBySipi for IntelTdx, Microvm, and Xen to preserve the original execution of INIT-SIPI-SIPI. Cc: Eric Dong <[email protected]> Cc: Ray Ni <[email protected]> Cc: Rahul Kumar <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Jiewen Yao <[email protected]> Cc: Jordan Justen <[email protected]> Signed-off-by: Yuanhao Xie <[email protected]> Acked-by: Gerd Hoffmann <[email protected]>
The CLANGDWARF profile sets both -Wno-tautological-compare and -Wno-tautological-constant-out-of-range-compare, but this prevents compile-time detection of certain errors. Drop these flags. Signed-off-by: Leif Lindholm <[email protected]> Cc: Rebecca Cran <[email protected]> Cc: Liming Gao <[email protected]> Cc: Bob Feng <[email protected]> Cc: Yuwei Chen <[email protected]> Cc: Ard Biesheuvel <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Reviewed-by: Rebecca Cran <[email protected]>
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 <[email protected]> Cc: Jian J Wang <[email protected]> Signed-off-by: Michael Kubacki <[email protected]> Reviewed-by: Jiewen Yao <[email protected]>
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 <[email protected]> Cc: Hao A Wu <[email protected]> Cc: Ray Ni <[email protected]> Signed-off-by: Nhi Pham <[email protected]> Reviewed-by: Liming Gao <[email protected]>
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 <[email protected]> Reviewed-by: Zhichao Gao <[email protected]>
… CR0 REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4511 With 64 bit build we are seeing the CD in control register CR 0 set. This causes the NEM to disabled for some specific bios profiles. Cc: Eric Dong <[email protected]> Reviewed-by: Ray Ni <[email protected]> Cc: Rahul Kumar <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Debkumar De <[email protected]> Cc: Catharine West <[email protected]> Signed-off-by: Wu, Mingliang <[email protected]>
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 <[email protected]> Cc: Jian J Wang <[email protected]> Cc: Liming Gao <[email protected]> Reviewed-by: Ray Ni <[email protected]>
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 <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Rebecca Cran <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]>
This patch adds below definitions from SMBIOS 3.7.0 into Smbios.h - ProcessorUpgradeSocketAM5 - ProcessorUpgradeSocketSP5 - ProcessorUpgradeSocketSP6 - ProcessorUpgradeSocketBGA883 - ProcessorUpgradeSocketBGA1190 - ProcessorUpgradeSocketBGA4129 - ProcessorUpgradeSocketLGA4710 - ProcessorUpgradeSocketLGA7529 Signed-off-by: Eduardo Cuevas Farfan <[email protected]> Reviewed-by: Star Zeng <[email protected]> Reviewed-by: Liming Gao <[email protected]>
This patch adds below definitions from SMBIOS 3.7.0 into QueryTable.c - ProcessorUpgradeSocketAM5 - ProcessorUpgradeSocketSP5 - ProcessorUpgradeSocketSP6 - ProcessorUpgradeSocketBGA883 - ProcessorUpgradeSocketBGA1190 - ProcessorUpgradeSocketBGA4129 - ProcessorUpgradeSocketLGA4710 - ProcessorUpgradeSocketLGA7529 Signed-off-by: Eduardo Cuevas Farfan <[email protected]> Reviewed-by: Star Zeng <[email protected]> Reviewed-by: Zhichao Gao <[email protected]>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4543 REF: https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-services-locatehandlebuffer CoreLocateHandleBuffer() can in certain cases, return an error and not free an allocated buffer. This scenario occurs if the first call to InternalCoreLocateHandle() returns success and the second call returns an error. On a successful return, LocateHandleBuffer() passes ownership of the buffer to the caller. However, the UEFI specification is not explicit about what the expected ownership of this buffer is in the case of an error. However, it is heavily implied by the code example given in section 7.3.15 of v2.10 of the UEFI specificaton that if LocateHandleBuffer() returns a non-successful status code then the ownership of the buffer does NOT transfer to the caller. This code example explicitly refrains from calling FreePool() if LocateHandleBuffer() returns an error. From a practical standpoint, it is logical to assume that a non-successful status code indicates that no buffer of handles was ever allocated. Indeed, in most error cases, LocateHandleBuffer() does not go far enough to get to the point where a buffer is allocated. Therefore, all existing users of this API must already be coded to support the case of a non-successful status code resulting in an invalid handle buffer being returned. Therefore, this change will not cause any backwards compatibility issues with existing code. In conclusion, this boils down to a fix for a memory leak that also brings the behavior of our LocateHandleBuffer() implementation into alignment with the original intentions of the UEFI specification authors. Reviewed-by: Michael D Kinney <[email protected]> Cc: Liming Gao <[email protected]> Cc: Jian J Wang <[email protected]> Cc: Dandan Bi <[email protected]> Signed-off-by: Nate DeSimone <[email protected]>
Instead of relying on raising the TPL to protect the critical sections that manipulate the global bitmask that keeps track of bounce buffer allocations, use compare-and-exchange to manage the global variable, and tweak the logic to line up with that. Given that IoMmuDxe implements a singleton protocol that is shared between multiple drivers, and considering the elaborate and confusing requirements in the UEFP spec regarding TPL levels at which protocol methods may be invoked, not relying on TPL levels at all is a more robust approach in this case. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2211060 Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Pedro Falcato <[email protected]>
PcdFirstTimeWakeUpAPsBySipi was recently introduced to indicate when the full INIT-SIPI-SIPI sequence can be skipped for AP bringup. It is true by default, but needs to be disabled for QEMU/OVMF where early INIT is not simulated. Commit 1d76560 ("OvmfPkg: Disable PcdFirstTimeWakeUpAPsBySipi.") added changes to disable it by default for OvmfPkg, but a similar change was not made for the AmdSev package. This breaks booting of SEV and SNP guests. Fix this defaulting PcdFirstTimeWakeUpAPsBySipi to false for AmdSev package, as was previously done for OvmfPkg variants. Fixes: eaffa1d ("UefiCpuPkg:Wake up APs after power-up or RESET through SIPI.") Signed-off-by: Michael Roth <[email protected]> Acked-by: Gerd Hoffmann <[email protected]>
I am moving this command outside of EDK2. This reverts commit 2c2cb23. Signed-off-by: Marcin Juszkiewicz <[email protected]> Reviewed-by: Leif Lindholm <[email protected]>
Booting an SEV guest with AmdSev OVMF package currently triggers the following assertion with QEMU: InstallQemuFwCfgTables: installed 7 tables PcRtc: Write 0x20 to CMOS location 0x32 [Variable]END_OF_DXE is signaled Initialize variable error flag (FF) ASSERT_EFI_ERROR (Status = Not Found) ASSERT [BdsDxe] /home/VT_BUILD/ovmf/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c(1711): !(((INTN)(RETURN_STATUS)(Status)) < 0) This seems to be due to commit 81dc0d8, which switched to using PlatformBootManagerLib instead of PlatformBootManagerLibGrub. That pulls in a dependency on gEfiS3SaveStateProtocolGuid provider being available (which is asserted for in BdsPlatform.c:PlatformBootManagerBeforeConsole()/SaveS3BootScript()), but the libraries that provide it aren't currently included in the build. Add them similarly to what's done for OvmfPkg. Fixes: 81dc0d8 ("OvmfPkg/AmdSev: stop using PlatformBootManagerLibGrub") Signed-off-by: Michael Roth <[email protected]> Acked-by: Gerd Hoffmann <[email protected]> Acked-by: Jiewen Yao <[email protected]>
The Hii form is named "MainFormState" while the EFI variable is named "PlatformConfig". This discrepancy in names causes the following SCT cases to fail on RiscVVirtQemu: ExtractConfigConformance ExtractConfigFunction ExtractConfig_Func Previous commit 16acacf addressed two of these issues, and this patch fixes the remaining one. Signed-off-by: Yin Wang <[email protected]> Reviewed-by: Dandan Bi <[email protected]>
Currently, unlike OVMF, ArmVirtQemu does not display any graphics, only the QEMU monitor. Graphics are helpful to confirm booting into an OS is successful, interacting with the EFI shell while getting separate logging messages, etc. This patch adds the QEMU parameters to launch a graphical window and add a USB keyboard and mouse, which is modeled as a tablet as it tracks better in QEMU than a generic mouse. virtio-gpu-pci is chosen as the graphics device as it is recommended by QEMU for the ARM virtual platform. The graphics and USB input devices will only be added to QEMU when QEMU_HEADLESS == FALSE, so CI builds will not attempt to use the graphics and if a user does not want graphics, they can add QEMU_HEADLESS=TRUE to the build cmdline. Signed-off-by: Oliver Smith-Denny <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]>
…QEMU" This reverts commit 173a7a7 Fixes https://bugzilla.tianocore.org/show_bug.cgi?id=4528 The build.sh qemu option starts the correct qemu executable for the selected architecture (build.sh -a option, or implicit) and uses the correct previously built OVMF image for the selected architecture and build target (build.sh -b option, or implicit). With this revert, the above step will fail if there is no matching previously built OVMF image. This is advantageous over rebuilding each time the build.sh qemu option is used (as in the reverted commit), because it provides a quick way to run a just-built OVMF image in place, while: a) Starting immediately (saving the time required for a rebuild on each usage, if the VM is started multiple times) b) Preserving the NVRAM contents between multiple runs (i.e. until the image is next rebuilt) Signed-off-by: Mike Beaton <[email protected]>
Register and initialize sha384/sha512 digest algorithms for PKCS#7 Handling. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3413 Cc: Jiewen Yao <[email protected]> Cc: Jian J Wang <[email protected]> Cc: Min Xu <[email protected]> Cc: Zeyi Chen <[email protected]> Cc: Fiona Wang <[email protected]> Cc: Xiaoyu Lu <[email protected]> Cc: Guomin Jiang <[email protected]> Cc: Michael D Kinney <[email protected]> Signed-off-by: Sheng Wei <[email protected]> Reviewed-by: Jiewen Yao <[email protected]>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3413 Cc: Jiewen Yao <[email protected]> Cc: Jian J Wang <[email protected]> Cc: Min Xu <[email protected]> Cc: Zeyi Chen <[email protected]> Cc: Fiona Wang <[email protected]> Signed-off-by: Sheng Wei <[email protected]> Reviewed-by: Jiewen Yao <[email protected]>
Add the new section for Secure Boot. Signed-off-by: Alexander Goncharov <[email protected]> Acked-by: Gerd Hoffmann <[email protected]>
Add DetectAndPreparePlatformVirtioDevicePath() helper function to setup virtio-mmio devices. Start with virtio-serial support. This makes virtio console usable with microvm. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Ard Biesheuvel <[email protected]>
mdkinney
requested review from
ardbiesheuvel,
samimujawar,
jyao1,
leiflindholm,
ZhichaoGao,
changab,
nate-desimone,
lgao4,
vlsunil,
ChaselChiu,
ajfish and
spbrogan
as code owners
tianocore-assign-reviewers
bot
requested review from
abdattar,
a user,
Benny3345678,
catharine-intl,
cbduggap,
cfernald,
chengangc,
dandanbi,
elmarco,
gguo11837463,
igorkulchytskyy,
jiaxinwu,
jljusten,
jongwu and
karthikkabbigere1
|
close |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.