summaryrefslogtreecommitdiffstats
path: root/UefiCpuPkg
Commit message (Collapse)AuthorAgeFilesLines
* UefiCpuPkg/UefiCpuPkg.ci.yaml: Add configuration for LicenseCheckShenglei Zhang2020-07-311-0/+3
| | | | | | | | | | | | | Add configuration IgnoreFiles for package config files. So users can rely on this to skip license conflict for some generated files. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg: Correct some typos.Guomin Jiang2020-07-286-10/+10
| | | | | | | | | | | | Correct some typos. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* UefiCpuPkg/CpuMpPei: Enable paging and set NP flag to avoid TOCTOU ↵Guomin Jiang2020-07-282-5/+30
| | | | | | | | | | | | | | | | | | (CVE-2019-11098) REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614 To avoid the TOCTOU, enable paging and set Not Present flag so when access any code in the flash range, it will trigger #PF exception. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Guomin Jiang <guomin.jiang@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* UefiCpuPkg/SecMigrationPei: Add initial PEIM (CVE-2019-11098)Michael Kubacki2020-07-2810-2/+709
| | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614 Adds a PEIM that republishes structures produced in SEC. This is done because SEC modules may not be shadowed in some platforms due to space constraints or special alignment requirements. The SecMigrationPei module locates interfaces that may be published in SEC and reinstalls the interface with permanent memory addresses. This is important if pre-memory address access is forbidden after memory initialization and data such as a PPI descriptor, PPI GUID, or PPI inteface reside in pre-memory. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Debkumar De <debkumar.de@intel.com> Cc: Harry Han <harry.han@intel.com> Cc: Catharine West <catharine.west@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* UefiCpuPkg/CpuMpPei: Add GDT migration support (CVE-2019-11098)Michael Kubacki2020-07-284-2/+60
| | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614 Moves the GDT to permanent memory in a memory discovered callback. This is done to ensure the GDT authenticated in pre-memory is not fetched from outside a verified location after the permanent memory transition. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* UefiCpuPkg: Add New Memory AttributesOleksiy Yakovlev2020-07-154-24/+8
| | | | | | | | | | | | | Add usage of EFI_MEMORY_SP and EFI_MEMORY_CPU_CRYPTO attributes introduced in UEFI 2.8. (UEFI 2.8, mantis 1919 and 1872). Use attributes bitmasks, defined in MdePkg. Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200702205039.52400-5-oleksiyy@ami.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Update EFI_MEMORY_CACHETYPE_MASK definitionOleksiy Yakovlev2020-07-151-1/+2
| | | | | | | | | | | Add EFI_MEMORY_WP attribute to EFI_MEMORY_CACHETYPE_MASK definition. Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com> Message-Id: <20200702205039.52400-4-oleksiyy@ami.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Eric Dong <eric.dong@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MtrrLib: Remove unnecessary API MtrrSetFixedMtrr()Ray Ni2020-07-142-44/+0
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2849 MtrrSetFixedMtrr() sets all the fixed MTRR settings. But in fact MtrrSetAllMtrrs() is always used by callers to set all MTRR settings including the fixed and variable ones. The patch removes the unnecessary API MtrrSetFixedMtrr() to simplify the MtrrLib API. There is no code in edk2 and edk2-platforms repo that calls MtrrSetFixedMtrr(). Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/MtrrLib: Remove unnecessary API MtrrSetVariableMtrr()Ray Ni2020-07-142-44/+0
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2849 MtrrSetVariableMtrr() sets all the variable MTRR settings. But in fact MtrrSetAllMtrrs() is always used by callers to set all MTRR settings including the fixed and variable ones. The patch removes the unnecessary API MtrrSetVariableMtrr() to simplify the MtrrLib API. There is no code in edk2 and edk2-platforms repo that calls MtrrSetVariableMtrr(). Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/MtrrLib: Remove unnecessary API MtrrGetVariableMtrr()Ray Ni2020-07-142-42/+2
| | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2849 MtrrGetVariableMtrr() returns all the variable MTRR settings. But in fact MtrrGetAllMtrrs() and MtrrGetMemoryAttributeInVariableMtrr() are used by callers to get the MTRR settings. The former one returns both the fixed and variable MTRR settings. The patch removes the unnecessary API MtrrGetVariableMtrr() to simplify the MtrrLib API. There is no code in edk2 and edk2-platforms repo that calls MtrrGetVariableMtrr(). Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg: PiSmmCpuDxeSmm skip MSR_IA32_MISC_ENABLE manipulation on AMDKirkendall, Garrett2020-07-074-5/+46
| | | | | | | | | | | | | | | | AMD does not support MSR_IA32_MISC_ENABLE. Accessing that register causes and exception on AMD processors. If Execution Disable is supported, but if the processor is an AMD processor, skip manipulating MSR_IA32_MISC_ENABLE[34] XD Disable bit. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Garrett Kirkendall <garrett.kirkendall@amd.com> Message-Id: <20200622131825.1352-5-Garrett.Kirkendall@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg: Move StandardSignatureIsAuthenticAMD to BaseUefiCpuLibKirkendall, Garrett2020-07-078-69/+67
| | | | | | | | | | | | | | | | | | | | | Refactor StandardSignatureIsAuthenticAMD into BaseUefiCpuLib from separate copies in BaseXApicLib, BaseXApicX2ApicLib, and MpInitLib. This allows for future use of StandarSignatureIsAuthinticAMD without creating more instances in other modules. This function allows IA32/X64 code to determine if it is running on an AMD brand processor. UefiCpuLib is already included directly or indirectly in all modified modules. Complete move is made in this change. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Garrett Kirkendall <garrett.kirkendall@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Message-Id: <20200622131825.1352-4-Garrett.Kirkendall@amd.com>
* UefiCpuPkg/SecCore: Add pre-memory AP vectorCole, Deric2020-06-231-7/+24
| | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2776 Add a vector at 0xFF000 (0xFFFFF000) that can be used by Init-SIPI-SIPI to start an AP before memory is initialized. This vector jumps into the same SEC entry point as the ordinary reset vector, with a special value of "AP" in the DI register. The platform-specific SEC code is expected to check for that value and take a different path for APs, if this feature is supported by the platform. Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Deric Cole <deric.cole@intel.com>
* UefiCpuPkg/MpService: GetProcessorInfo returns 6-level topologyRay Ni2020-05-151-0/+19
| | | | | | | | | | | | | | | | | | | | Intel SDM introduces 6-levels for describing the CPU topology: * Package * Module * Tile * Die * Core * Thread A PI spec ECR was submitted to enhance CPU_MP PPI/Protocol to support returning such information through GetProcessorInfo(). An accordingly change was implemented and pushed to edk2-staging. Now the PI spec has been published. The patch is cherry-picked from edk2-staging to edk2. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/CpuExceptionHandler: Revert CpuExceptionHandler binary patchingLendacky, Thomas2020-05-111-19/+6
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2340 Now that an XCODE5 specific CpuExceptionHandlerLib library is in place, revert the changes made to the ExceptionHandlerAsm.nasm in commit 2db0ccc2d7fe ("UefiCpuPkg: Update CpuExceptionHandlerLib pass XCODE5 tool chain") so that binary patching of flash code is not performed. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Acked-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <810f67d8604c054c09d17a22f0bcfaeb41ee8e3b.1588856809.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/CpuExceptionHandler: Make XCODE5 changes toolchain specificLendacky, Thomas2020-05-117-3/+479
| | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2340 Commit 2db0ccc2d7fe ("UefiCpuPkg: Update CpuExceptionHandlerLib pass XCODE5 tool chain") introduced binary patching into the exception handling support. CPU exception handling is allowed during SEC and this results in binary patching of flash, which should not be done. Separate the changes from commit 2db0ccc2d7fe into an XCODE5 toolchain specific file, Xcode5ExceptionHandlerAsm.nasm, and create a new SEC INF file for the XCODE5 version of CpuExceptionHandlerLib. Since binary patching is allowed when running outside of flash, switch the Dxe, Pei and Smm versions of the CpuExceptionHandlerLib over to use the Xcode5ExceptionHandlerAsm.nasm file to retain current functionality. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <9075570487616c731033a5738f6a444a15d71b74.1588856809.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Remove Executable attribute from MpLib.hLeo Duran2020-05-061-0/+0
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2678 This patch fixes a file permission issue introduced by accident. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Avoid ApInitReconfig in PEI.Dong, Eric2020-04-301-2/+11
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2683 In PEI phase, AP already been waked up through ApInitConfig, so it can directly wake up it through change wakup buffer instead of use ApInitReconfig flag. It can save some time. Change code to only use ApInitReconfig flag in DXE phase which must need to update the wake up buffer. Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Restore IDT context for APs.Eric Dong2020-04-301-11/+23
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2683 This patch fixes an assertion because AP can't find the CpuMpData. When AP is waken up through Init-Sipi-Sipi, AP's IDT should be restored to pre-allocated buffer so AP can get the CpuMpData through the IDT base address. Current code already has logic to handle this when CpuMpData-> InitFlag is ApInitConfig but misses the logic when CpuMpData->InitFlag is ApInitReconfig. This patch fixes this gap. Reviewed-by: Ray Ni <ray.ni@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Add missing explicit PcdLib dependencyHao A Wu2020-04-233-0/+3
| | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2632 Both PEI and DXE instances of the MpInitLib are using PcdLib APIs, but none of them list the dependency of the PcdLib in INF & header files. This commit will explicitly add such dependency in .H and .INF files. Test done: Library level build pass for VS2015x86 tool chain Cc: Eric Dong <eric.dong@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Remove useless code in ResetTokens.Dong, Eric2020-04-131-20/+0
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2388 After remove Used parameter, below code in ResetTokens can also be removed: 1. The RunningApCount parameter will be reset in GetFreeToken. 2. The ReleaseSpinLock should be called in ReleaseToken function, Code in this function seems like a later fix if ReleaseToken not Release it. We should remove code here and fix the real issue if existed. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Remove Used parameter.Dong, Eric2020-04-132-6/+5
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2388 After patch "UefiCpuPkg/PiSmmCpuDxeSmm: Improve the performance of GetFreeToken()" which adds new parameter FirstFreeToken, it's not need to use Uses parameter. This patch used to remove this parameter. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Improve the performance of GetFreeToken()Ray Ni2020-04-132-47/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Today's GetFreeToken() runs at the algorithm complexity of O(n) where n is the size of the token list. The change introduces a new global variable FirstFreeToken and it always points to the first free token. So the algorithm complexity of GetFreeToken() decreases from O(n) to O(1). The improvement matters when some SMI code uses StartupThisAP() service for each of the AP such that the algorithm complexity becomes O(n) * O(m) where m is the AP count. As next steps, 1. PROCEDURE_TOKEN.Used field can be optimized out because all tokens before FirstFreeToken should have "Used" set while all after FirstFreeToken should have "Used" cleared. 2. ResetTokens() can be optimized to only reset tokens before FirstFreeToken. v2: add missing line in InitializeDataForMmMp. v3: update copyright year to 2020. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/MpInitLib: Add out attribute for parameter.GuoMinJ2020-03-273-3/+3
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2553 The comment haven't indicate the output attribute. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Guomin Jiang <guomin.jiang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MpInitLib DXE: Add PCD to control AP status check intervalHao A Wu2020-03-274-13/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2627 The commit will introduce a static PCD to specify the periodic interval for checking the AP status when MP services StartupAllAPs() and StartupThisAP() are being executed in a non-blocking manner. Or in other words, specifies the interval for callback function CheckApsStatus(). The purpose is to provide the platform owners with the ability to choose the proper interval value to trigger CheckApsStatus() according to: A) The number of processors in the system; B) How MP services (StartupAllAPs & StartupThisAP) being used. Setting the PCD to a small value means the AP status check callback will be triggered more frequently, it can benefit the performance for the case when the BSP uses WaitForEvent() or uses CheckEvent() in a loop to wait for AP(s) to complete the task, especially when the task can be finished considerably fast on AP(s). An example is within function CpuFeaturesInitialize() under UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c, where BSP will perform the same task with APs and requires all the processors to finish the task before BSP proceeds to its next task. Setting the PCD to a big value, on the other hand, can reduce the impact on BSP by the time being consumed in CheckApsStatus(), especially when the number of processors is huge so that the time consumed in CheckApsStatus() is not negligible. The type of the PCD is UINT32, which means the maximum possible interval value can be set to: 4,294,967,295 microseconds = 4,295 seconds = 71.58 minutes = 1.19 hours which should be sufficient for usage. For least impact, the default value of the new PCD will be the same with the current interval value. It will be set to 100,000 microseconds, which is 100 milliseconds. Unitest done: A) OS boot successfully; B) Use debug message to confirm the 'TriggerTime' parameter for the 'SetTimer' service is the same before & after this patch. Cc: Eric Dong <eric.dong@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Brian J. Johnson <brian.johnson@hpe.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: fix S3 Resume for CPU hotplugLaszlo Ersek2020-03-041-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "ACPI_CPU_DATA.NumberOfCpus" field is specified as follows, in "UefiCpuPkg/Include/AcpiCpuData.h" (rewrapped for this commit message): // // The number of CPUs. If a platform does not support hot plug CPUs, // then this is the number of CPUs detected when the platform is booted, // regardless of being enabled or disabled. If a platform does support // hot plug CPUs, then this is the maximum number of CPUs that the // platform supports. // The InitializeCpuBeforeRebase() and InitializeCpuAfterRebase() functions in "UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c" try to restore CPU configuration on the S3 Resume path for *all* CPUs accounted for in "ACPI_CPU_DATA.NumberOfCpus". This is wrong, as with CPU hotplug, not all of the possible CPUs may be present at the time of S3 Suspend / Resume. The symptom is an infinite wait. Instead, the "mNumberOfCpus" variable should be used, which is properly maintained through the EFI_SMM_CPU_SERVICE_PROTOCOL implementation (see SmmAddProcessor(), SmmRemoveProcessor(), SmmCpuUpdate() in "UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c"). When CPU hotplug is disabled, "mNumberOfCpus" is constant, and equals "ACPI_CPU_DATA.NumberOfCpus" at all times. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Eric Dong <eric.dong@intel.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-3-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Eric Dong <eric.dong@intel.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> [lersek@redhat.com: shut up UINTN->UINT32 warning from Windows VS2019 PR]
* UefiCpuPkg/MpInitLib: Skip reading PlatformId on AMD processors.edk2-stable202002Leo Duran2020-03-022-2/+36
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2556 This patch uses CPUID signature check to skip reading the PlatformId MSR, which is not implemented on AMD processors. The PlatformId is used for loading microcode patches, which is also not supported and AMD-based platforms. To mitigate the PlatformId dependency, PcdCpuMicrocodePatchAddress and PcdCpuMicrodePatchRegionSize must be set to 0 (default value), in order to bypass microcode loading code paths. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg RegisterCpuFeaturesLib: Match data type and format specifierZeng, Star2020-02-191-12/+12
| | | | | | | | | | | | | | | | | Match data type and format specifier for printing. 1. Type cast ProcessorNumber and FeatureIndex to UINT32 as %d only expects a UINT32. 2. Use %08x instead of %08lx for CacheControl to print Index as it is UINT32 type. 3. Use %016lx instead of %08lx for MemoryMapped to print (Index | LShiftU64 (HighIndex, 32)) as it is UINT64 type. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg: Remove FIT based microcode shadow logic from MpInitLib.Siyuan Fu2020-02-149-123/+183
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c7c964b and dd01704 add header file for FIT table and update MpInitLib to support FIT based microcode shadow operation. There are comments that FIT is Intel specific specification instead of industry standard, which should not be placed in EDK2 MdePkg and UefiCpuPkg. So this patch adds a platform PPI for the microcode shadow logic, and remove the FIT related code from EDK2. The FIT based microcode shadow support will be implemented as a new platform PEIM in IntelSiliconPkg in edk2-platforms. This patch doesn't provide a DXE version shadow microcode protocol, a platform which only uses DxeMpInitLib instance only supports PCD based microcode shadowing. A detailed design doc can be found here: https://edk2.groups.io/g/devel/files/Designs/2020/0214/Support%20 the%202nd%20Microcode%20FV%20Flash%20Region.pdf TEST: Tested on FIT enabled platform. BZ: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuFeature: Introduce First to indicate 1st unit.Ray Ni2020-02-142-1/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1584 The flow of CPU feature initialization logic is: 1. BSP calls GetConfigDataFunc() for each thread/AP; 2. Each thread/AP calls SupportFunc() to detect its own capability; 3. BSP calls InitializeFunc() for each thread/AP. There is a design gap in step #3. For a package scope feature that only requires one thread of each package does the initialization operation, what InitializeFunc() currently does is to do the initialization operation only CPU physical location Core# is 0. But in certain platform, Core#0 might be disabled in hardware level which results the certain package scope feature isn't initialized at all. The patch adds a new field First to indicate the CPU's location in its parent scope. First.Package is set for all APs/threads under first package; First.Core is set for all APs/threads under first core of each package; First.Thread is set for the AP/thread of each core. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Rename [Before|After]FeatureBitMaskRay Ni2020-02-142-33/+41
| | | | | | | The patch doesn't have any functionality impact. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Delete CPU_FEATURE_[BEFORE|AFTER]Ray Ni2020-02-143-22/+13
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1366 Commit b3c71b472dff2c02f0cc38d7a1959cfb2ba8420d supported MSR setting in different scopes. It added below macro: CPU_FEATURE_THREAD_BEFORE CPU_FEATURE_THREAD_AFTER CPU_FEATURE_CORE_BEFORE CPU_FEATURE_CORE_AFTER CPU_FEATURE_PACKAGE_BEFORE CPU_FEATURE_PACKAGE_AFTER And it re-interpreted CPU_FEATURE_BEFORE as CPU_FEATURE_THREAD_BEFORE and CPU_FEATURE_AFTER as CPU_FEATURE_THREAD_AFTER. This patch retires CPU_FEATURE_BEFORE and CPU_FEATURE_AFTER completely. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/MpInitLib: Not pass microcode info between archs in CPU_MP_DATAHao A Wu2020-02-115-12/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2465 Commit 89164babec: UefiCpuPkg/MpInitLib: don't shadow the microcode patch twice. attempted to use 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' fields to avoid loading the microcode patches data into memory again in the DXE phase. However, the CPU_MP_DATA structure has members with type 'UINTN' or pointer before the microcode patch related fields. This may cause issues when PEI and DXE are of different archs (e.g. PEI - IA32, DXE - x64), since the microcode patch related fields will have different offsets in the CPU_MP_DATA structure. Commit 88bd066166: UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATA tried to resolve the above-mentioned issue by relocating the fields 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' before members with different size between different archs. But it failed to take the case of pre-built binaries (e.g. FSP) into consideration. Binaries can be built when the code base had a different version of the CPU_MP_DATA structure definition. This may cause issues when accessing these microcode patch related fields, since their offsets are different (between PEI phase in the binaries and DXE phase in current code implementation). This commit will use the newly introduced EDKII microcode patch HOB instead for the DXE phase to get the information of the loaded microcode patches data done in the PEI phase. And the 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' fields in CPU_MP_DATA will not be used to pass information between phases. For pre-built binaries, they can be classified into 3 types with regard to the time when they are being built: A. Before commit 89164babec (In other words, 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' were not being used to skip microcode load in DXE) For this case, the EDKII microcode patch HOB will not be produced. This commit will load the microcode patches data again in DXE. Such behavior is the same with the code base back then. B. After commit 89164babec, before commit e1ed55738e (In other words, 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' being used to skip microcode load in DXE, but failed to work properly between differnt archs.) For this case, the EDKII microcode patch HOB will not be produced as well. This commit will also load the microcode patches data again in DXE. But since commit 89164babec failed to keep the detection and application of microcode patches working properly in DXE after skipping the load, we fall back to the origin behavior (that is to load the microcode patches data again in DXE). C. After commit e1ed55738e (In other words, EDKII microcode patch HOB will be produced.) For this case, it will have the same behavior with the BIOS built from the current source codes. Cc: Michael Kubacki <michael.a.kubacki@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* Revert UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATAHao A Wu2020-02-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 88bd06616617ef2569f093f7b51893c11ad78e26. REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2465 Commit 88bd0661661 relocates the 'MicrocodePatchAddress' and 'MicrocodePatchRegionSize' fields in structure CPU_MP_DATA to ensure that they can be properly passed between different architectures. However, such change is not backward compatible with the scenario like pre-existing binaries such as FSP. These binaries are built when the code base has a different version of the CPU_MP_DATA structure definition. This may cause issues when accessing the 'MicrocodePatchAddress' and 'MicrocodePatchRegionSize' fields, since their offsets are different (between PEI phase in the FSP binaries and DXE phase in current code implementation). Cc: Michael Kubacki <michael.a.kubacki@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/Smm: Fix various typosAntoine Coeur2020-02-107-12/+12
| | | | | | | | | | | | | | Fix various typos in comments and documentation. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-79-philmd@redhat.com>
* UefiCpuPkg/PiSmm: Fix various typosAntoine Coeur2020-02-109-18/+18
| | | | | | | | | | | | | | Fix various typos in comments and documentation. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-78-philmd@redhat.com>
* UefiCpuPkg/CpuDxe: Fix few typosAntoine Coeur2020-02-108-15/+15
| | | | | | | | | | | | | | Fix few typos in comments and documentation. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-77-philmd@redhat.com>
* UefiCpuPkg/MpInitLib: Always get CPUID & PlatformID in MicrocodeDetect()Hao A Wu2020-02-061-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2498 Commit fd30b00707 updated the logic in function MicrocodeDetect() that will directly use the CPUID and PlatformID information from the 'CpuData' field in the CPU_MP_DATA structure, instead of collecting these information for each processor via AsmCpuid() and AsmReadMsr64() calls respectively. At that moment, this approach worked fine for APs. Since: a) When the APs are waken up for the 1st time (1st MpInitLibInitialize() entry at PEI phase), the function InitializeApData() will be called for each AP and the CPUID and PlatformID information will be collected. b) During the 2nd entry of MpInitLibInitialize() at DXE phase, when the APs are waken up again, the function InitializeApData() will not be called, which means the CPUID and PlatformID information will not be collected. However, the below logics in MicrocodeDetect() function: CurrentRevision = GetCurrentMicrocodeSignature (); IsBspCallIn = (ProcessorNumber == (UINTN)CpuMpData->BspNumber) ? TRUE : FALSE; if (CurrentRevision != 0 && !IsBspCallIn) { // // Skip loading microcode if it has been loaded successfully // return; } will ensure that the microcode detection and application will be skipped due to the fact that such process has already been done in the PEI phase. But after commit 396e791059, which removes the above skip loading logic, the CPUID and PlatformID information on APs will be used upon the 2nd entry of the MpInitLibInitialize(). But since the CPUID and PlatformID information has not been collected, it will bring issue to the microcode detection process. This commit will update the logic in MicrocodeDetect() back to always collecting the CPUID and PlatformID information explicitly. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Fix possible uninitialized 'InitFlag' fieldHao A Wu2020-01-191-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2474 Previous commit d786a17232: UefiCpuPkg/MpInitLib: Reduce the size when loading microcode patches Removed the below assignments for the 'InitFlag' field of CPU_MP_DATA structure in function MpInitLibInitialize() when APs are waken up to do some initialize sync: CpuMpData->InitFlag = ApInitReconfig; ... CpuMpData->InitFlag = ApInitDone; The above commit mistakenly assumed the 'InitFlag' field will have a value of 'ApInitDone' when the APs have been successfully waken up before. And since there is no explicit comparision for the 'InitFlag' field with the 'ApInitReconfig' value. The commit removed those assignments. However, under some cases (e.g. when variable OldCpuMpData is not NULL, which means function CollectProcessorCount() will not be called), removing the above assignments will left the 'InitFlag' field being uninitialized with a value of 0, which is a invalid value for the type of 'InitFlag' (AP_INIT_STATE). It may potentially cause the WakeUpAP() function to run some unnecessary codes when the APs have been successfully waken up before: if (CpuMpData->WakeUpByInitSipiSipi || CpuMpData->InitFlag != ApInitDone) { ResetVectorRequired = TRUE; AllocateResetVector (CpuMpData); FillExchangeInfoData (CpuMpData); SaveLocalApicTimerSetting (CpuMpData); } This commit will address the above-mentioned issue. Test done: * OS boot on a real platform with multi processors Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: fix 2M->4K page splitting regression for PDEsLaszlo Ersek2020-01-171-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 4eee0cc7cc0d ("UefiCpuPkg/PiSmmCpu: Enable 5 level paging when CPU supports", 2019-07-12), the Page Directory Entry setting was regressed (corrupted) when splitting a 2MB page to 512 4KB pages, in the InitPaging() function. Consider the following hunk, displayed with $ git show --function-context --ignore-space-change 4eee0cc7cc0db > // > // If it is 2M page, check IsAddressSplit() > // > if (((*Pd & IA32_PG_PS) != 0) && IsAddressSplit (Address)) { > // > // Based on current page table, create 4KB page table for split area. > // > ASSERT (Address == (*Pd & PHYSICAL_ADDRESS_MASK)); > > Pt = AllocatePageTableMemory (1); > ASSERT (Pt != NULL); > > + *Pd = (UINTN) Pt | IA32_PG_RW | IA32_PG_P; > + > // Split it > - for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++) { > - Pt[PtIndex] = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS); > + for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++, Pt++) { > + *Pt = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS); > } // end for PT > *Pd = (UINT64)(UINTN)Pt | mAddressEncMask | PAGE_ATTRIBUTE_BITS; > } // end if IsAddressSplit > } // end for PD First, the new assignment to the Page Directory Entry (*Pd) is superfluous. That's because (a) we set (*Pd) after the Page Table Entry loop anyway, and (b) here we do not attempt to access the memory starting at "Address" (which is mapped by the original value of the Page Directory Entry). Second, appending "Pt++" to the incrementing expression of the PTE loop is a bug. It causes "Pt" to point *right past* the just-allocated Page Table, once we finish the loop. But the PDE assignment that immediately follows the loop assumes that "Pt" still points to the *start* of the new Page Table. The result is that the originally mapped 2MB page disappears from the processor's view. The PDE now points to a "Page Table" that is filled with garbage. The random entries in that "Page Table" will cause some virtual addresses in the original 2MB area to fault. Other virtual addresses in the same range will no longer have a 1:1 physical mapping, but be scattered over random physical page frames. The second phase of the InitPaging() function ("Go through page table and set several page table entries to absent or execute-disable") already manipulates entries in wrong Page Tables, for such PDEs that got split in the first phase. This issue has been caught as follows: - OVMF is started with 2001 MB of guest RAM. - This places the main SMRAM window at 0x7C10_1000. - The SMRAM management in the SMM Core links this SMRAM window into "mSmmMemoryMap", with a FREE_PAGE_LIST record placed at the start of the area. - At "SMM Ready To Lock" time, PiSmmCpuDxeSmm calls InitPaging(). The first phase (quoted above) decides to split the 2MB page at 0x7C00_0000 into 512 4KB pages, and corrupts the PDE. The new Page Table is allocated at 0x7CE0_D000, but the PDE is set to 0x7CE0_E000 (plus attributes 0x67). - Due to the corrupted PDE, the second phase of InitPaging() already looks up the PTE for Address=0x7C10_1000 in the wrong place. The second phase goes on to mark bogus PTEs as "NX". - PiSmmCpuDxeSmm calls SetMemMapAttributes(). Address 0x7C10_1000 is at the base of the SMRAM window, therefore it happens to be listed in the SMRAM map as an EfiConventionalMemory region. SetMemMapAttributes() calls SmmSetMemoryAttributes() to mark the region as XP. However, GetPageTableEntry() in ConvertMemoryPageAttributes() fails -- address 0x7C10_1000 is no longer mapped by anything! -- and so the attribute setting fails with RETURN_UNSUPPORTED. This error goes unnoticed, as SetMemMapAttributes() ignores the return value of SmmSetMemoryAttributes(). - When SetMemMapAttributes() reaches another entry in the SMRAM map, ConvertMemoryPageAttributes() decides it needs to split a 2MB page, and calls SplitPage(). - SplitPage() calls AllocatePageTableMemory() for the new Page Table, which takes us to InternalAllocMaxAddress() in the SMM Core. - The SMM core attempts to read the FREE_PAGE_LIST record at 0x7C10_1000. Because this virtual address is no longer mapped, the firmware crashes in InternalAllocMaxAddress(), when accessing (Pages->NumberOfPages). Remove the useless assignment to (*Pd) from before the loop. Revert the loop incrementing and the PTE assignment to the known good version. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1789335 Fixes: 4eee0cc7cc0db74489b99c19eba056b53eda6358 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Shadow microcode patch according to FIT microcode entry.Siyuan Fu2020-01-107-67/+222
| | | | | | | | | | | | | | | | | | | | | | | | The existing MpInitLib will shadow the microcode update patches from flash to memory and this is done by searching microcode region specified by PCD PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize. This brings a limition to platform FW that all the microcode patches must be placed in one continuous flash space. This patch shadows microcode update according to FIT microcode entries if it's present, otherwise it will fallback to original logic (by PCD). A new featured PCD gUefiCpuPkgTokenSpaceGuid.PcdCpuShadowMicrocodeByFit is added for enabling/disabling this support. TEST: Tested on FIT enabled platform. BZ: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuCommonFeaturesLib: SMXE bit of CR4 should setJason Voelz2020-01-101-0/+9
| | | | | | | | Add code to set SMXE in CR4 in the SmxInitialize flow when SMX is enabled. Signed-off-by: Jason Voelz <jason.voelz@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Add missed comments for parameter.Eric Dong2020-01-101-0/+2
| | | | | | | | | | | This issue caused by below change: SHA-1: b948a496150f4ae4f656c0f0ab672608723c80e6 * UefiCpuPkg/PiSmmCpuDxeSmm: Pre-allocate PROCEDURE_TOKEN buffer REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2388 Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg: Always load microcode patch on AP processor.Siyuan, Fu2020-01-081-6/+0
| | | | | | | | | | | | | | | | | | | | This patch updates the microcode loader to always perform a microcode detect and load on both BSP and AP processor. This is to fix a potential microcode revision mismatch issue in below situation: 1. Assume there are two microcode co-exists in flash: one production version and one debug version microcode. 2. FIT loads production microcode to BSP and all AP. 3. UefiCpuPkg loader loads debug microcode to BSP, and skip the loading on AP. As a result, different microcode patches are loaded to BSP and AP, and trigger microcode mismatch error during OS boot. BZ link: https://bugzilla.tianocore.org/show_bug.cgi?id=2431 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg: Remove alignment check when calculate microcode size.Siyuan Fu2020-01-082-21/+6
| | | | | | | | | | | | | | | | | | | | This patch removes the unnecessary alignment check on microcode patch TotalSize introduced by commit d786a172. The TotalSize has already been checked with 1K alignment and MAX_ADDRESS in previous code as below: if ( (UINTN)MicrocodeEntryPoint > (MAX_ADDRESS - TotalSize) || ((UINTN)MicrocodeEntryPoint + TotalSize) > MicrocodeEnd || (DataSize & 0x3) != 0 || (TotalSize & (SIZE_1KB - 1)) != 0 || TotalSize < DataSize ) { Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: improve the coding styleEric Dong2020-01-081-9/+9
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2434 Current code use below loops to enumerate the CPUs: for (Index = mMaxNumberOfCpus; Index-- > 0;) { it has no issue but not easy for the developers to read the code. Update above code to below style, for (Index = 0; Index < mMaxNumberOfCpus; Index++) { It make the developers easy to read and consistent with other similar cases in this driver. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* Revert "UefiCpuPkg/PiSmmCpuDxeSmm: Fix buffer overflow issue."Eric Dong2020-01-081-8/+8
| | | | | | | | | | This reverts commit 123b720eeb371e0a31eb727bcf59255b584e355f. The commit message for commit 123b720eeb37 is not correct. Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Pre-allocate PROCEDURE_TOKEN bufferEric Dong2020-01-022-87/+109
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2388 Token is new introduced by MM MP Protocol. Current logic allocate Token every time when need to use it. The logic caused SMI latency raised to very high. Update logic to allocate Token buffer at driver's entry point. Later use the token from the allocated token buffer. Only when all the buffer have been used, then need to allocate new buffer. Former change (9caaa79dd7e078ebb4012dde3b3d3a5d451df609) missed PROCEDURE_TOKEN part, this change covers it. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Remove redundant microcode fields in CPU_MP_DATAHao A Wu2020-01-022-42/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous commits have introduced below fields in structure CPU_AP_DATA: UINT32 ProcessorSignature; UINT8 PlatformId; UINT64 MicrocodeEntryAddr; which store the information of: A. CPUID B. Platform ID C. Detected microcode patch entry address (including the microcode patch header) for each processor within system. Therefore, the below fields in structure CPU_MP_DATA: UINT32 ProcessorSignature; UINT32 ProcessorFlags; UINT64 MicrocodeDataAddress; UINT32 MicrocodeRevision; which store the BSP's information of: A. CPUID B. Platform ID C. The address and revision of detected microcode patch are redundant and can be removed. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATAHao A Wu2020-01-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The below 2 microcode patch related fields in structure CPU_MP_DATA: UINT64 MicrocodePatchAddress; UINT64 MicrocodePatchRegionSize; They will be passed from PEI phase and be reused DXE phase. Previously, these 2 fields were placed after some fields with type 'UINTN', this will lead to different field offset in different architecture for them. This commit will move them before the fields with different size in different architecture to ensure they can be properly used in DXE phase. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-16 12:29:02 +0000