mirror of
https://github.com/acidanthera/audk.git
synced 2025-04-08 17:05:09 +02:00
a9e3458ba7
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>