summaryrefslogtreecommitdiffstats
path: root/UefiCpuPkg/Library
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-116-3/+472
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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/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-272-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/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-146-110/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-141-1/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-142-10/+10
| | | | | | | | | | | | | | | | | | | | | | | 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-106-10/+10
| | | | | | | | | | | | | | 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/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: Shadow microcode patch according to FIT microcode entry.Siyuan Fu2020-01-105-67/+210
| | | | | | | | | | | | | | | | | | | | | | | | 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: 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/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>
* UefiCpuPkg/MpInitLib: Produce EDKII microcode patch HOBHao A Wu2020-01-025-8/+100
| | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2430 This commit will update the MpInitLib to: A. Collect the base address and size information after microcode patches being loaded into memory; B. Collect the detected microcode patch for each processor within system; C. Based on the collected information, produce the EDKII microcode patch HOB. 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: Reduce the size when loading microcode patchesHao A Wu2020-01-023-62/+340
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2429 This commit will attempt to reduce the copy size when loading the microcode patches data from flash into memory. Such optimization is done by a pre-process of the microcode patch headers (on flash). A microcode patch will be loaded into memory only when the below 3 criteria are met: A. With a microcode patch header (which means the data is not padding data between microcode patches); B. The 'ProcessorSignature' & 'ProcessorFlags' fields in the header match at least one processor within system; C. If the Extended Signature Table exists in a microcode patch, the 'ProcessorSignature' & 'ProcessorFlag' fields in the table entries match at least one processor within system. Criterion B and C will require all the processors to be woken up once to collect their CPUID and Platform ID information. Hence, this commit will move the copy, detect and apply of microcode patch on BSP and APs after all the processors have been woken up. 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: Collect processors' CPUID & Platform ID infoHao A Wu2020-01-022-1/+15
| | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2429 This commit will collect the CPUID and Platform ID information for each processor within system. They will be stored in the CPU_AP_DATA structure. These information will be used in the next commit to decide whether a microcode patch will be loaded into memory. 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>
* UefiCpuPkg: Update the coding stylesShenglei Zhang2019-12-041-1/+1
| | | | | | | | | | | | In MpLib.c, remove the white space on a new line. In PageTbl.c and PiSmmCpuDxeSmm.h, update the comment style. 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: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuCommonFeaturesLib: Remove XD enable/disable logicRay Ni2019-11-133-108/+1
| | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2329 XD (ExecutionDisable) feature, when turned on, allows page table entry BIT63 set to 1 indicating the memory pointed by the page table is disallowed to execute. DxeIpl::CreateIdentityMappingPageTables() enables the XD when CPU supports it. Later DxeCore modifies the page table to set the BIT63 to protect the stack/heap to disallow code execution in stack/heap. UefiCpuPkg/CpuCommonFeaturesLib enables/disables the XD feature according to PcdCpuFeaturesSetting. When XD is disabled, GP fault is generated immediately because some page entries have BIT63 set. To fix this issue, this patch removes the XD feature logic from UefiCpuPkg/CpuCommonFeaturesLib so the XD feature is only taken care of by DxeIpl. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MpInitLib: Remove global variable X2ApicEnableRay Ni2019-11-052-9/+6
| | | | | | | | | | | | | | | | | | | | MpInitLib sets X2ApicEnable in two places. 1. CollectProcessorCount() This function is called when MpInitLibInitialize() hasn't been called before. It sets X2ApicEnable and later in the same function it configures all CPUs to operate in X2 APIC mode. 2. MpInitLibInitialize() The X2ApicEnable setting happens when this function is called in second time. But after that setting, no code consumes that flag. With the above analysis and with the purpose of simplifying the code, the X2ApicEnable in #1 is changed to local variable and the #2 can be changed to remove the setting of X2ApicEnable. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MpInitLib: Set X2ApicEnable flag from BSPRay Ni2019-11-051-9/+16
| | | | | | | | | | | | | | | | | | | | | Today's logic sets X2ApicEnable flag in each AP's initialization path when InitFlag == ApInitConfig. Since all CPUs update the same global data, a spin-lock is used to avoid modifications from multiple CPUs happen at the same time. The spin-lock causes two problems: 1. Potential performance downgrade. 2. Undefined behavior when improper timer lib is used. For example we saw certain platforms used AcpiTimerLib from PcAtChipsetPkg and that library depends on retrieving PeiServices from idtr. But in fact AP's (idtr - 4) doesn't point to PeiServices. The patch simplifies the code to let BSP set the X2ApicEnable flag so the spin-lock acquisition from AP is not needed any more. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MpInitLib: honor the platform's boot CPU count in AP detectionLaszlo Ersek2019-10-113-40/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - If a platform boots such that the boot CPU count is smaller than PcdCpuMaxLogicalProcessorNumber, then the platform cannot use the "fast AP detection" logic added in commit 6e1987f19af7. (Which has been documented as a subset of use case (2) in the previous patch.) Said logic depends on the boot CPU count being equal to PcdCpuMaxLogicalProcessorNumber. If the equality does not hold, the platform either has to wait too long, or risk missing APs due to an early timeout. - The platform may not be able to use the variant added in commit 0594ec417c89 either. (Which has been documented as use case (1) in the previous patch.) See commit 861218740d6d. When OVMF runs on QEMU/KVM, APs may check in with the BSP in arbitrary order, plus the individual AP may take arbitrarily long to check-in. If "NumApsExecuting" falls to zero mid-enumeration, APs will be missed. Allow platforms to specify the exact boot CPU count, independently of PcdCpuMaxLogicalProcessorNumber. In this mode, the BSP waits for all APs to check-in regardless of timeout. If at least one AP fails to check-in, then the AP enumeration hangs forever. That is the desired behavior when the exact boot CPU count is known in advance. (A hung boot is better than an AP checking-in after timeout, and executing code from released storage.) Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: expand comment on initial AP enumerationLaszlo Ersek2019-10-111-7/+29
| | | | | | | | | | | Before adding another AP enumeration mode, clarify the documentation on the current logic. No functional changes. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/CpuExceptionHandlerLib: Fix split lockJohn E Lofgren2019-09-201-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2150 v4: The v3 posting didn't do what it promised to do, so do it now for real. V3 changes: change to mov instruction (non locking instuction) instead of xchg to simplify design. V2 changes: Add xchg 16 bit instructions to handle sgdt and sidt base 63:48 bits and 47:32 bits. Add comment to explain why xchg 64bit isnt being used Split lock happens when a locking instruction is used on mis-aligned data that crosses two cachelines. If close source platform enables Alignment Check Exception(#AC), They can hit a double fault due to split lock being in CpuExceptionHandlerLib. sigt and sgdt saves 10 bytes to memory, 8 bytes is base and 2 bytes is limit. The data is mis-aligned, can cross two cacheline, and a xchg instruction(locking instuction) is being utilize. Signed-off-by: John E Lofgren <john.e.lofgren@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leafDonald Kuo2019-08-2110-0/+622
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1909 Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Amy Chan <amy.chan@intel.com> Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com> Signed-off-by: Donald Kuo <donald.kuo@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/CpuCommonFeaturesLib: Use new macros.Dong, Eric2019-08-214-132/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040 Below code is current implementation: if (MsrRegister[ProcessorNumber].Bits.Lock == 0) { CPU_REGISTER_TABLE_WRITE_FIELD ( ProcessorNumber, Msr, MSR_IA32_FEATURE_CONTROL, MSR_IA32_FEATURE_CONTROL_REGISTER, Bits.Lock, 1 ); } 1. In first normal boot, the Bits.Lock is 0, 1 will be added into the register table and then will set to the MSR. 2. Trig warm reboot, MSR value preserves. After normal boot phase, the Bits.Lock is 1, so it will not be added into the register table during the warm reboot phase. 3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is not added in register table, so it's still 0 after resume. This is not an expect behavior. The expect value is the value should always 1 after booting or resuming from S3. The root cause for this issue is 1. driver bases on current value to insert the "set value action" to the register table. 2. Some MSRs may reserve their value during warm reboot. The solution for this issue is using new added macros for the MSRs which preserve value during warm reboot. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Supports test then write new value logic.Dong, Eric2019-08-211-1/+30
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040 Supports new logic which test current value before write new value. Only write new value when current value not same as new value. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Combine CR read/write action.Dong, Eric2019-08-211-47/+63
| | | | | | Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.Dong, Eric2019-08-211-3/+41
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040 Add below new micros which test the current value before write the new value. Only write new value when current value not same as new value. CPU_REGISTER_TABLE_TEST_THEN_WRITE32 CPU_REGISTER_TABLE_TEST_THEN_WRITE64 CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD Also add below API: CpuRegisterTableTestThenWrite Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Clean up useless ConsoleLogLock spinlock.Eric Dong2019-08-092-2/+0
| | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2060 Remove the useless ConsoleLogLock spinlock. Signed-off-by: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Update code to include register definitions from MdePkgNi, Ray2019-08-097-21/+21
| | | | | | | Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Enable 5-level paging for AP when BSP's enabledNi, Ray2019-08-094-2/+32
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008 MpInitLib is the library that's responsible to wake up APs to provide MP PPI and Protocol services. The patch synchronizes BSP's CR4.LA57 to each AP's CR4.LA57. Without this change, AP may enter to GP fault when BSP's 5-level page table is set to AP during AP wakes up. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Remove debug message.Eric Dong2019-08-061-22/+0
| | | | | | | | | | | | This debug message may be called by BSP and APs. It may caused ASSERT when APs call this debug code. In order to avoid system boot assert, Remove this debug message. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MpInitLib: don't shadow the microcode patch twice.Eric Dong2019-08-021-29/+33
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1982 MpInitLibInitialize in MpLib.c will be invoked on both PEI and DXE CPU code, MicrocodeDetect would be performed twice and copy Microcode from flash to memory twice as well, which consider as duplicate work to lead longer boot time. This patch just use microcode memory copied in PEI phase if exist. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Start all processors simultaneously.Eric Dong2019-07-295-23/+53
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1973 For semaphore type register, it required all processors to do the task at the same time. Current logic begins BSP's task after all APs have finished their tasks. This will caused set semaphore task hang if semaphore has package level type. This patch use new EDKII_PEI_MP_SERVICES2_PPI to start all processors at the same time to fix the potential hang issue. Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLibUp: Add MpInitLibStartupAllCPUs API.Eric Dong2019-07-291-0/+35
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1973 Add new MpInitLibStartupAllCPUs API uses to start all processors at the same time. Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Add MpInitLibStartupAllCPUs API.Eric Dong2019-07-294-10/+67
| | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1973 Add new MpInitLibStartupAllCPUs API uses to start all processors at the same time. Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: avoid use dynamic PCD.Dong, Eric2019-07-183-102/+79
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1972 Function in this library may be used by APs. Assert will be trig if AP uses dynamic pcd. This patch enhance the current code, remove the unnecessary usage of dynamic PCD. This change try to avoid report this issue again later. Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Avoid AP calls PeiServices table.Eric Dong2019-07-182-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1972 AP calls CollectProcessorData() to collect processor info. CollectProcessorData function finally calls PcdGetSize function to get DynamicPCD PcdCpuFeaturesSetting value. PcdGetSize will use PeiServices table which caused below assert info: Processor Info: Package: 1, MaxCore : 4, MaxThread: 1 Package: 0, Valid Core : 4 ASSERT [CpuFeaturesPei] c:\projects\jsl\jsl_v1193\Edk2\MdePkg\Library \PeiServicesTablePointerLibIdt\PeiServicesTablePointer.c(48): PeiServices != ((void *) 0) This change uses saved global pcd size instead of calls PcdGetSize to fix this issue. Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-26 14:25:53 +0000