Sync with edk2 oct 2023 v4 #91
Open
+387,796
−67,244
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
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]>
The qemu/kvm SMM emulation uses the AMD SaveState layout. So, now that we have AMD SaveState support merged we can just use Amd/SmramSaveStateMap.h, QemuSmramSaveStateMap.h is not needed any more. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Ard Biesheuvel <[email protected]>
Be consistent with pl011-based serial console setup. Suggested-by: Laszlo Ersek <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Laszlo Ersek <[email protected]> Acked-by: Ard Biesheuvel <[email protected]>
The include guard is incomplete and does not define the macro. Cc: Michael D Kinney <[email protected]> Cc: Liming Gao <[email protected]> Cc: Zhiguang Liu <[email protected]> Cc: Rebecca Cran <[email protected]> Signed-off-by: Michael Kubacki <[email protected]> Reviewed-by: Rebecca Cran <[email protected]> Reviewed-by: Michael D Kinney <[email protected]> Reviewed-by: Liming Gao <[email protected]>
Add MpService2Ppi field in SMM_S3_RESUME_STATE of AcpiS3Context.h. It will be used to wakeup AP to do the CPU initialization during smm s3 boot flow in following patches. With this field, we can avoid sending InitSipiSipi to wakeup AP. Signed-off-by: Dun Tan <[email protected]> Reviewed-by: Ray Ni <[email protected]> Reviewed-by: Jian J Wang <[email protected]> Cc: Liming Gao <[email protected]>
Prepare MpService2Ppi in S3Resume when PEI and SMM env run in the same execution mode. Then smm s3 code can use Mp Service to wakeup AP instead of only sending InitSipiSipi. Signed-off-by: Dun Tan <[email protected]> Cc: Eric Dong <[email protected]> Reviewed-by: Ray Ni <[email protected]> Cc: Rahul Kumar <[email protected]>
Add assert for invalid excution mode combination of 64bit PEI + 32bit DXE. Signed-off-by: Dun Tan <[email protected]> Cc: Eric Dong <[email protected]> Reviewed-by: Ray Ni <[email protected]> Cc: Rahul Kumar <[email protected]>
This commit is code logic refinement for s3 boot flow in CpuS3.c. It doesn't change any code functionality. This commit implementes InitializeAp and InitializeBsp as a single function since they are doing almost the same thing. Then both BSP and AP will execute the same function InitializeCpuProcedure to do CPU initialization. This can make the code logic easier to understand. Signed-off-by: Dun Tan <[email protected]> Cc: Eric Dong <[email protected]> Reviewed-by: Ray Ni <[email protected]> Cc: Rahul Kumar <[email protected]>
Use MpService2Ppi to wakeup AP in s3 boot flow during initializing CPU. If mSmmS3ResumeState->MpService2Ppi is not 0, then BSP will use MpService2Ppi->StartupAllCPUs to do CPU initialization for both BSP and AP instead of only sending InitSipiSipi for AP. Signed-off-by: Dun Tan <[email protected]> Cc: Eric Dong <[email protected]> Reviewed-by: Ray Ni <[email protected]> Cc: Rahul Kumar <[email protected]>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4504 The BaseRngLibTimerLib allows to generate number based on a timer. This mechanism allows to have a basic non-secure implementation for non-production platforms. To bind and identify Random Number Generators implementations with a GUID, an unsafe GUID should be added. This GUID cannot be added to the MdePkg unless it is also added to a specification. To keep the MdePkg self-contained, copy the BaseRngLibTimerLib to the MdeModulePkg. This will allow to define an unsafe Rng GUID in a later patch in the MdeModulePkg. The MdePkg implementation will be removed later. This allows to give some time to platform owners to switch to the MdeModulePkg implementation. Signed-off-by: Pierre Gondois <[email protected]> Reviewed-by: Sami Mujawar <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Kun Qin <[email protected]>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4504 To keep the MdePkg self-contained and avoid dependencies on GUIDs defined in other packages, the BaseRngLibTimer was moved to the MdePkg. Add a constructor to warn and request to use the MdeModulePkg implementation. Signed-off-by: Pierre Gondois <[email protected]> Reviewed-by: Liming Gao <[email protected]> Reviewed-by: Sami Mujawar <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Kun Qin <[email protected]>
In order to use PcdCpuRngSupportedAlgorithm in the MdePkg in a following patch and to avoid making the MdePkg dependent on another package, move PcdCpuRngSupportedAlgorithm to the MdePkg. As the Pcd is only used for AARCH64, place it in an AARCH64 specific sections. Signed-off-by: Pierre Gondois <[email protected]> Reviewed-by: Liming Gao <[email protected]> Reviewed-by: Sami Mujawar <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Acked-by: Jiewen Yao <[email protected]> Tested-by: Kun Qin <[email protected]>
The DxeRngLib tries to generate a random number using the 3 NIST SP 800-90 compliant DRBG algorithms, i.e. 256-bits CTR, HASH and HMAC. If none of the call is successful, the fallback option is the default RNG algorithm of the EFI_RNG_PROTOCOL. This default algorithm might be an unsafe implementation. Try requesting the Raw algorithm before requesting the default one. Signed-off-by: Pierre Gondois <[email protected]> Reviewed-by: Sami Mujawar <[email protected]> Reviewed-by: Liming Gao <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Kun Qin <[email protected]>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441 The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple implementations, some of them are unsafe (e.g. BaseRngLibTimerLib). To allow the RngDxe to detect when such implementation is used, a GetRngGuid() function is added in a following patch. Prepare GetRngGuid() return values and add a gEfiRngAlgorithmArmRndr to describe a Rng algorithm accessed through Arm's RNDR instruction. [1] states that the implementation of this algorithm should be compliant to NIST SP900-80. The compliance is not guaranteed. [1] Arm Architecture Reference Manual Armv8, for A-profile architecture sK12.1 'Properties of the generated random number' Signed-off-by: Pierre Gondois <[email protected]> Reviewed-by: Sami Mujawar <[email protected]> Reviewed-by: Liming Gao <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Kun Qin <[email protected]>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441 The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple implementations, some of them are unsafe (e.g. BaseRngLibTimerLib). To allow the RngDxe to detect when such implementation is used, a GetRngGuid() function is added in a following patch. Prepare GetRngGuid() return values and add a gEdkiiRngAlgorithmUnSafe to describe an unsafe implementation, cf. the BaseRngLibTimerLib. Signed-off-by: Pierre Gondois <[email protected]> Reviewed-by: Sami Mujawar <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Kun Qin <[email protected]>
The EFI_RNG_PROTOCOL can use the RngLib. The RngLib has multiple implementations, some of them are unsafe (e.g. BaseRngLibTimerLib). To allow the RngDxe to detect when such implementation is used, add a GetRngGuid() function to the RngLib. Signed-off-by: Pierre Gondois <[email protected]> Reviewed-by: Liming Gao <[email protected]> Reviewed-by: Sami Mujawar <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Kun Qin <[email protected]>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4151 The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple implementations, some of them are unsafe (e.g. BaseRngLibTimerLib). To allow the RngDxe to detect when such implementation is used, a GetRngGuid() function was added in a previous patch. The EFI_RNG_PROTOCOL can advertise multiple algorithms through Guids. The PcdCpuRngSupportedAlgorithm is currently used to advertise the RngLib in the Arm implementation. The issues of doing that are: - the RngLib implementation might not use CPU instructions, cf. the BaseRngLibTimerLib - most platforms don't set PcdCpuRngSupportedAlgorithm A GetRngGuid() was added to the RngLib in a previous patch, allowing to identify the algorithm implemented by the RngLib. Make use of this function and place the unsage algorithm at the last position in the mAvailableAlgoArray. Signed-off-by: Pierre Gondois <[email protected]> Reviewed-by: Sami Mujawar <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Acked-by: Jiewen Yao <[email protected]> Tested-by: Kun Qin <[email protected]>
tianocore-assign-reviewers
bot
requested review from
jongwu and
karthikkabbigere1
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
Signed-off-by: Michael D Kinney <[email protected]>
tianocore-assign-reviewers
bot
requested review from
kilaterlee,
kprakas2,
kraxel,
lcp,
LiuZhiguang001,
liyi77,
lzeng14,
MarsDoge,
mxu9,
nicklela,
pierregondois,
rahul1-kumar,
ruleof2,
SaloniKasbekar and
tedkuo1
|
Please accept invite to join EDK II Reviewers team ==> Executing Valid Owner Checker (8.569222507s) |
|
Please accept invite to join EDK II Maintainers team ==> Executing Valid Owner Checker (5.07225407s) |
Signed-off-by: Michael D Kinney <[email protected]>
tianocore-assign-reviewers
bot
requested review from
tlendacky,
tperard,
weltling,
xuweiintel,
YuweiChen1110 and
zhangbaoqi-ls
Signed-off-by: Michael D Kinney <[email protected]>
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.
Ignore code review requests. Syncing with latest edk2 and refreshing actions