summaryrefslogtreecommitdiffstats
path: root/UefiCpuPkg
Commit message (Collapse)AuthorAgeFilesLines
* UefiCpuPkg: Fix issue that IsModified is wrongly set in PageTableMapZhiguang Liu2024-02-222-6/+16
| | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4614 About the IsModified, current function doesn't consider that hardware also may change the pagetable. The issue is that in the first call of internal function PageTableLibMapInLevel, the function assume page table is not changed, and add ASSERT to check. But hardware may change the page table, which cause the ASSERT happens. Fix the issue by adding addtional condition to only check if the page table is changed when the software want to modify the page table. Also, add more comment to explain this behavior. Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Crystal Lee <CrystalLee@ami.com.tw> Cc: Pedro Falcato <pedro.falcato@gmail.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiCpuPkg/CpuMpPei: Don't write CR3 in ConvertMemoryPageToNotPresentZhiguang Liu2024-02-221-2/+2
| | | | | | | | | | | | | | | | | The purpose of writing CR3 in ConvertMemoryPageToNotPresent is just to flush TLB, because CR3 won't be changed in function ConvertMemoryPageToNotPresent. After ConvertMemoryPageToNotPresent, there is always a flush TLB function. Also, because ConvertMemoryPageToNotPresent in called in a loop, to improve performance, there is no need to flush TLB inside ConvertMemoryPageToNotPresent. Just flushing TLB after the loop is enough. Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiCpuPkg/CpuPageTableLib: Enhance function header for PageTableMap()Zhiguang Liu2024-02-222-0/+2
| | | | | | | | | | | PageTableMap() only modifies the PageTable root pointer when creating from zero. Explicitly explain it in function header. Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Check BspIndex first before lock cmpxchgJiaxin Wu2024-02-211-5/+7
| | | | | | | | | | | | | | | | | | | This patch is to check BspIndex first before lock cmpxchg operation. If BspIndex has not been set, then do the lock cmpxchg, otherwise, the APs don't need to lock cmpxchg the BspIndex value since the BSP election has been done. It's the optimization to lower the resource contention caused by the atomic compare exchange operation, so as to improve the SMI performance for BSP election. Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Kinney Michael D <michael.d.kinney@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Avoid BspIndex typecastingJiaxin Wu2024-02-211-6/+6
| | | | | | | | | | | | | | | | Use MAX_UINT32 directly instead of typecasting from signed to unsigned value. Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Kinney Michael D <michael.d.kinney@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: fix NULL deref when gSmmBaseHobGuid is missingedk2-stable202402Laszlo Ersek2024-02-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4682 Fixes: 725acd0b9cc0 Before commit 725acd0b9cc0 ("UefiCpuPkg: Avoid assuming only one smmbasehob", 2023-12-12), PiCpuSmmEntry() used to look up "gSmmBaseHobGuid", and allocate "mCpuHotPlugData.SmBase" regardless of the GUID's presence: > - mCpuHotPlugData.SmBase = (UINTN *)AllocatePool (sizeof (UINTN) * mMaxNumberOfCpus); > - ASSERT (mCpuHotPlugData.SmBase != NULL); After commit 725acd0b9cc0, PiCpuSmmEntry() -> GetSmBase() would allocate "mCpuHotPlugData.SmBase" only on the success path, and no allocation would be performed on *any* of the error paths. This caused a problem: if "mCpuHotPlugData.SmBase" was left NULL because the GUID HOB was missing, PiCpuSmmEntry() would still be supposed to allocate "mCpuHotPlugData.SmBase", just like earlier. However, because commit 725acd0b9cc0 conflated the two possible error modes (out of SMRAM, and no GUID HOB), PiCpuSmmEntry() could not decide whether it should allocate "mCpuHotPlugData.SmBase", or not. Currently, we never allocate if GetSmBase() fails -- for any reason --, which means that on platforms that don't produce the GUID HOB, "mCpuHotPlugData.SmBase" is left NULL, leading to null pointer dereferences later, in PiCpuSmmEntry(). Now that a prior patch in the series distinguishes the two error modes from each other, we can tell exactly when the GUID HOB is not found, and reinstate the earlier "mCpuHotPlugData.SmBase" allocation for that case. (With an actual error check thrown in, in addition to the original "assertion".) Cc: Dun Tan <dun.tan@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reported-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Rahul Kumar <rahul1.kumar@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: distinguish GetSmBase() failure modesLaszlo Ersek2024-02-141-12/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4682 Commit 725acd0b9cc0 ("UefiCpuPkg: Avoid assuming only one smmbasehob", 2023-12-12) introduced a helper function called GetSmBase(), replacing the lookup of the first and only "gSmmBaseHobGuid" GUID HOB and unconditional "mCpuHotPlugData.SmBase" allocation, with iterated lookups plus conditional memory allocation. This introduced a new failure mode for setting "mCpuHotPlugData.SmBase". Namely, before commit 725acd0b9cc0, "mCpuHotPlugData.SmBase" would be allocated regardless of the GUID HOB being absent. After the commit, "mCpuHotPlugData.SmBase" could remain NULL if the GUID HOB was absent, *or* one of the memory allocations inside GetSmBase() failed; and in the former case, we'd even proceed to the rest of PiCpuSmmEntry(). In relation to this conflation of distinct failure modes, commit 725acd0b9cc0 actually introduced a NULL pointer dereference. Namely, a NULL "mCpuHotPlugData.SmBase" is not handled properly at all now. We're going to fix that NULL pointer dereference in a subsequent patch; however, as a pre-requisite for that we need to tell apart the failure modes of GetSmBase(). For memory allocation failures, return EFI_OUT_OF_RESOURCES. Move the "assertion" that SMRAM cannot be exhausted happen out to the caller (PiCpuSmmEntry()). Strengthen the assertion by adding an explicit CpuDeadLoop() call. (Note: GetSmBase() *already* calls CpuDeadLoop() if (NumberOfProcessors != MaxNumberOfCpus).) For the absence of the GUID HOB, return EFI_NOT_FOUND. For good measure, make GetSmBase() STATIC (it should have been STATIC from the start). This is just a refactoring, no behavioral difference is intended (beyond the explicit CpuDeadLoop() upon SMRAM exhaustion). Cc: Dun Tan <dun.tan@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Rahul Kumar <rahul1.kumar@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: Add a new CPU IO 2 driver named CpuMmio2DxeChao Li2024-02-064-0/+624
| | | | | | | | | | | | | | | | | | | | | | CpuIo2Dxe only supports IO to access to CPU IO. Some ARCHs that do not implement ports for CPU IO require MMIO to access PCI IO, and they pretty much put the IO devices under the LPC bus, which is usually under the PCIe/PCI bus. CpuMmio2Dxe was added to meet these needs. CpuMmio2Dxe depends on PcdPciIoTranslation. The code is copied from ArmPkg. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584 Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Chao Li <lichao@loongson.cn> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm:Map SMRAM in 4K page granularityDun Tan2024-02-061-24/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is to map SMRAM in 4K page granularity during SMM page table initialization(SmmInitPageTable) so as to avoid the SMRAM paging-structure layout change when SMI happens (PerformRemainingTasks). The reason is to avoid the Paging-Structure change impact to the multiple Processors. Refer SDM section "4.10.4" & "4.10.5". Currently, SMM BSP needs to update the SMRAM range paging attribute in smm page table according to the SmmMemoryAttributesTable when SMM ready to lock happens. If the SMRAM range is not 4k mapped in page table, the page table update process may split 1G/2M paging entries to 4k ones.Meanwhile, all APs are still running in SMI, which might access the affected linear-address range between the time of modification and the time of invalidation access. That will be a potential problem leading exception happens. Signed-off-by: Dun Tan <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: Add more Paging mode enumerationDun Tan2024-02-061-1/+7
| | | | | | | | | | | | | Add more Paging mode enumeration in CpuPageTableLib to support forced mapping a range in 4K page granularity. Signed-off-by: Dun Tan <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: Reduce and optimize access to attributeZhou Jianfeng2024-02-061-33/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is to reduce and optimize access to attribute in CpuPageTableLib. Unreasonable writing to attribute of page table may leads to expection. The assembly code for C code Pnle->Bits.Present = Attribute->Bits.Present looks like: and dword [rcx], 0xfffffffe and eax, 0x1 or [rcx], eax In case Pnle->Bits.Present and Attribute->Bits.Present is 1, Pnle->Bits.Present will be set to 0 for short time(2 instructions) which is unexpected. If some other core is accessing the page, it may leads to expection. This change reduce and optimize access to attribute of page table, attribute of page table is set only when it need to be changed. Signed-off-by: Zhou Jianfeng <jianfeng.zhou@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: Add cache operations support for Arch protoDhaval Sharma2024-02-042-0/+15
| | | | | | | | | | | | | | With CMO operations available for RISC-V, utilize them in CPU Architecture protocol. Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Sunil VL <sunilvl@ventanamicro.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* UefiCpuPkg/BaseXApic[X2]ApicLib: Implements AMD extended cpu topologyAbdul Lateef Attar2024-01-312-2/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for AMD's new extended topology. If processor supports CPUID 80000026 leaf then obtain the topology information using new method. Algorithm: if CPUID is AMD: then check for AMD's extended cpu tology leaf. if yes then extract cpu tology based on AMD programmer manual's instruction. else then fallback to existing topology function. endif endif Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com> Message-Id: <d93822d37fd25dafd32795758cf47263b432e102.1705549445.git.AbdulLateef.Attar@amd.com> Acked-by: Ray Ni <ray.ni@intel.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
* UefiCpuPkg: change name of gMpInformationHobGuid2Dun Tan2024-01-156-11/+11
| | | | | | | | | | | | | Change name of gMpInformationHobGuid2 to gMpInformation2HobGuid. It's to align with the file name MpInformation2.h and the structure name MP_INFORMATION2_HOB_DATA. Signed-off-by: Dun Tan <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg:Limit PhysicalAddressBits in special caseDun Tan2024-01-151-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | When creating smm page table, limit maximum supported physical addresses bits returned by CalculateMaximumSupportAddress() to 47 if 5-Level Paging is disabled. This commit is to avoid issue that more than 47-bit physical addresses are requested in smm page table when 5-level paging is disabled. 4-level paging supports translating 48-bit linear addresses to 52-bit physical addresses. Since linear addresses are sign-extended, linear-address space of 4-level paging is: [0, 2^47-1] and [0xffff8000_00000000, 0xffffffff_ffffffff]. So only [0, 2^47-1] linear-address range maps to the identical physical-address range when 5-Level paging is disabled. Signed-off-by: Dun Tan <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Optimize PatchSmmSaveStateMap and FlushTlbForAllZhi Jin2024-01-121-32/+65
| | | | | | | | | | | | | | | PatchSmmSaveStateMap patches the SMM entry (code) and SmmSaveState region (data) for each core, which can be improved to flush TLB once after all the memory entries have been patched. FlushTlbForAll flushes TLB for each core in serial, which can be improved to flush TLB in parallel. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Signed-off-by: Zhi Jin <zhi.jin@intel.com>
* UefiCpuPkg/CpuTimerDxeRiscV64: Add support for SstcSunil V L2024-01-113-3/+49
| | | | | | | | | | | | | | | | | Sstc extension allows to program the timer and receive the interrupt without using an SBI call. This reduces the latency to generate the timer interrupt. So, detect whether Sstc extension is supported and use the stimecmp register directly to program the timer interrupt. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com> Reviewed-by: Dhaval Sharma <dhaval@rivosinc.com>
* UefiCpuPkg: Check lower 24 bits of ProcessorNumberduntan2024-01-091-1/+4
| | | | | | | | | | | | | | | | | | | | | Check lower 24 bits of ProcessorNumber instead of the value of ProcessorNumber in the API MpInitLibGetProcessorInfo() of MpInitLibUp instance. Lower 24 bits of ProcessorNumber contains the actual processor number. The BIT24 of input ProcessorNumber might be set to indicate if the EXTENDED_PROCESSOR_INFORMATION will be retrived. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Min Xu <min.m.xu@intel.com> Message-Id: <20240108050804.1718-3-dun.tan@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: set EXTENDED_PROCESSOR_INFORMATION to 0duntan2024-01-094-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Set EXTENDED_PROCESSOR_INFORMATION to 0 in API MpInitLibGetProcessorInfo() of MpInitLibUp. This commit use ZeroMem() to set all fileds in output EFI_PROCESSOR_INFORMATION to 0 before StatusFlag field is reassigned. Previously EXTENDED_PROCESSOR_INFORMATION in the API MpInitLibGetProcessorInfo() of MpInitLibUp is ignored. In PEI/DXE MpInitLib, EXTENDED_PROCESSOR_INFORMATION will be retrived when BIT24 of input ProcessorNumber is set. This commit can avoid garbage in the output structure in MpInitLibGetProcessorInfo() of MpInitLibUp. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Min Xu <min.m.xu@intel.com> Message-Id: <20240108050804.1718-2-dun.tan@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/CpuMpPei: Parallel get stack base for better performance.Zhiguang Liu2024-01-051-27/+29
| | | | | | | | | | | | | Parallel run the function GetStackBase for all APs for better performance. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Daoxiang Li <daoxiang.li@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Reduce one round BSP & AP syncJiaxin Wu2023-12-261-16/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After BSP returned from SmmCoreEntry, there are several rounds BSP and AP sync in BSP handler: 1 .ReleaseAllAPs(); /// Notify all APs to exit. if (SmmCpuFeaturesNeedConfigureMtrrs()) { 2. SmmCpuSyncWaitForAPs(); /// Wait for all APs to program MTRRs. 3. ReleaseAllAPs(); /// Signal APs to restore MTRRs. } 4. SmmCpuSyncWaitForAPs(); /// Wait for all APs to complete pending tasks including MTRR. 5. ReleaseAllAPs(); /// Signal APs to Reset states. 6. SmmCpuSyncWaitForAPs(); /// Gather APs to exit SMM synchronously. Before step 6 and after step 5, BSP performs below items: A. InitializeDebugAgent() /// Stop source level debug. B. SmmCpuUpdate() /// Perform pending operations for hot-plug. C. Present = FALSE; /// Clear the Present flag of BSP. For InitializeDebugAgent(), BSP needs to wait all APs complete pending tasks and then notify all APs to stop source level debug. So, above step 4 & step 5 are required for InitializeDebugAgent(). For SmmCpuUpdate(), it's to perform pending operations for hot-plug CPUs take effect in next SMI. Existing APs in SMI do not reply on the CPU switch & hot-add & hot-remove operations. So, no need step 4 and step 5 for additional one round BSP & AP sync. Step 6 can make sure all APs are ready to exit SMM, then hot-plug operation can take effect in next SMI. For BSP "Present" flag, AP does not reply on it. No need step 4 and step 5 for additional one round BSP & AP sync. Based on above analysis, step 4 and step 5 are only required if need configure MTRR and support SMM source level debug. So, we can reduce one round BSP and AP sync if both are unsupported. With this change, SMI performance can be improved. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Invert ReleaseAllAPs & InitializeDebugAgentJiaxin Wu2023-12-261-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Existing BSP handler stops source level debug, then call ReleaseAllAPs to tell all APs can reset the Present flag to FALSE: InitializeDebugAgent (); /// Stop source level debug ReleaseAllAPs (); /// Tell APs can reset "Present" flag. This patch is to invert ReleaseAllAPs & InitializeDebugAgent: ReleaseAllAPs (); /// Tell APs can reset "Present" flag. InitializeDebugAgent (); /// Stop source level debug After this change, there is no negative impact since SMM source level debug feature doesn't depend on AP's "Present" flag, no impact to the SMM source level debug capability. Instead, the change will benefit the AP source level debug capability to trace its "Present" flag change for SMI exit since the source level debug feature will be stopped after each AP has the chance to reset the state. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Align BSP and AP sync logic for SMI exitJiaxin Wu2023-12-261-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Below piece of code is the BSP and AP sync logic for SMI exit. 1. AP after finish the scheduled procedure: if (SmmCpuFeaturesNeedConfigureMtrrs ()) { SmmCpuSyncReleaseBsp (); SmmCpuSyncWaitForBsp (); ... } SmmCpuSyncReleaseBsp (); SmmCpuSyncWaitForBsp (); SmmCpuSyncReleaseBsp (); 2. BSP after return from SmmCoreEntry: SmmCpuSyncWaitForAPs (); if (SmmCpuFeaturesNeedConfigureMtrrs ()) { ReleaseAllAPs (); ... SmmCpuSyncWaitForAPs (); } ReleaseAllAPs (); SmmCpuSyncWaitForAPs(); This patch is to make BSP same as AP sync logic: if (SmmCpuFeaturesNeedConfigureMtrrs ()) { SmmCpuSyncWaitForAPs (); ReleaseAllAPs (); ... } SmmCpuSyncWaitForAPs (); ReleaseAllAPs (); SmmCpuSyncWaitForAPs(); With the change, it will be easy to understand the sync flow as below: BSP: SmmCpuSyncWaitForAPs <-- AP: SmmCpuSyncReleaseBsp BSP: ReleaseAllAPs --> AP: SmmCpuSyncWaitForBsp This patch doesn't have function impact. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Check SMM Debug Agent support or notJiaxin Wu2023-12-264-11/+23
| | | | | | | | | | | | | | This patch is to check SMM Debug Agent support or not before InitializeDebugAgent. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Consume SmmCpuSyncLibJiaxin Wu2023-12-203-213/+68
| | | | | | | | | | | | | | | | | | | There is the SmmCpuSyncLib Library class define the SMM CPU sync flow, which is aligned with existing SMM CPU driver sync behavior. This patch is to consume SmmCpuSyncLib instance directly. With this change, SMM CPU Sync flow/logic can be customized with different implementation no matter for any purpose, e.g. performance tuning, handle specific register, etc. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Simplify RunningApCount decrementJiaxin Wu2023-12-201-1/+1
| | | | | | | | | | | | | | | | To decrease the count of RunningApCount, InterlockedDecrement is enough to achieve that. This patch is to simplify RunningApCount decrement. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Implements SmmCpuSyncLib library instanceJiaxin Wu2023-12-203-0/+688
| | | | | | | | | | | | | | | | | | | | | | | | | | | Implements SmmCpuSyncLib Library instance. The instance refers the existing SMM CPU driver (PiSmmCpuDxeSmm) sync implementation and behavior: 1.Abstract Counter and Run semaphores into SmmCpuSyncCtx. 2.Abstract CPU arrival count operation to SmmCpuSyncGetArrivedCpuCount(), SmmCpuSyncCheckInCpu(), SmmCpuSyncCheckOutCpu(), SmmCpuSyncLockDoor(). Implementation is aligned with existing SMM CPU driver. 3. Abstract SMM CPU Sync flow to: BSP: SmmCpuSyncReleaseOneAp --> AP: SmmCpuSyncWaitForBsp BSP: SmmCpuSyncWaitForAPs <-- AP: SmmCpuSyncReleaseBsp Semaphores release & wait during sync flow is same as existing SMM CPU driver. 4.Same operation to Counter and Run semaphores by leverage the atomic compare exchange. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Adds SmmCpuSyncLib library classJiaxin Wu2023-12-202-0/+293
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Intel is planning to provide different SMM CPU Sync implementation along with some specific registers to improve the SMI performance, hence need SmmCpuSyncLib Library for Intel. This patch is to: 1.Adds SmmCpuSyncLib Library class in UefiCpuPkg.dec. 2.Adds SmmCpuSyncLib.h function declaration header file. For the new SmmCpuSyncLib, it provides 3 sets of APIs: 1. ContextInit/ContextDeinit/ContextReset: ContextInit() is called in driver's entrypoint to allocate and initialize the SMM CPU Sync context. ContextDeinit() is called in driver's unload function to deinitialize SMM CPU Sync context. ContextReset() is called before CPU exist SMI, which allows CPU to check into the next SMI from this point. 2. GetArrivedCpuCount/CheckInCpu/CheckOutCpu/LockDoor: When SMI happens, all processors including BSP enter to SMM mode by calling CheckInCpu(). The elected BSP calls LockDoor() so that CheckInCpu() will return the error code after that. CheckOutCpu() can be called in error handling flow for the CPU who calls CheckInCpu() earlier. GetArrivedCpuCount() returns the number of checked-in CPUs. 3. WaitForAPs/ReleaseOneAp/WaitForBsp/ReleaseBsp WaitForAPs() & ReleaseOneAp() are called from BSP to wait the number of APs and release one specific AP. WaitForBsp() & ReleaseBsp() are called from APs to wait and release BSP. The 4 APIs are used to synchronize the running flow among BSP and APs. BSP and AP Sync flow can be easy understand as below: BSP: ReleaseOneAp --> AP: WaitForBsp BSP: WaitForAPs <-- AP: ReleaseBsp Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Optimize Semaphore Sync between BSP and APJiaxin Wu2023-12-201-14/+58
| | | | | | | | | | | | | | | | | | This patch is to define 3 new functions (WaitForBsp & ReleaseBsp & ReleaseOneAp) used for the semaphore sync between BSP & AP. With the change, BSP and AP Sync flow will be easy understand as below: BSP: ReleaseAllAPs or ReleaseOneAp --> AP: WaitForBsp BSP: WaitForAllAPs <-- AP: ReleaseBsp Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Avoid assuming only one smmbasehobDun Tan2023-12-121-32/+149
| | | | | | | | | | | | | | Modify the gSmmBaseHobGuid consumption code to remove the asuumption that there is only one gSmmBaseHobGuid. If the CPU number is big enough, there will be more than one SmmBaseHob in the HOB list. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: Cache core type in MpInfo2 HOBDun Tan2023-12-122-2/+59
| | | | | | | | | | Cache core type in MpInfo2 HOB by CpuMpPei module. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: Add a new field in MpInfo2 HOBDun Tan2023-12-121-0/+2
| | | | | | | | | | Add new field CoreType in gMpInformationHobGuid2 Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxeDun Tan2023-12-123-51/+168
| | | | | | | | | | | | | | Consume MpInfo2Hob in PiSmmCpuDxe driver to get NumberOfProcessors, MaxNumberOfCpus and EFI_PROCESSOR_INFORMATION for all CPU from the MpInformation2 HOB. This can avoid calling MP service. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: Build MpInfo2HOB in CpuMpPeiDun Tan2023-12-123-2/+96
| | | | | | | | | | | | | | | | Build MpInfo2HOB in CpuMpPei module so that later PiSmmCpuDxe or other StandaloneMm module can consume the HOB. Since there might be more one gMpInformationHobGuid2 in HOB list, CpuMpPei create a gMpInformationHobGuid2 with 0 value NumberOfProcessors field in the end of the process to indicate it's the last MP_INFORMATION2_HOB. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkgDun Tan2023-12-122-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create gMpInformationHobGuid2 in UefiCpuPkg. Currently, there is a gMpInformationHobGuid defined, created and consumed only in StandaloneMmPkg. The HOB contains the EFI_PROCESSOR_INFORMATION structure for each CPU and the number of processors. This is the same as the information that PiSmmCpuDxeSmm uses MpService Protocol to get. This new gMpInformationHobGuid2 also contains the NumberOfProcessors and the EFI_PROCESSOR_INFORMATION for each CPU. Also the HOB is extended to support the case that the maximum HOB length is not enough for all CPU. So there might be more than one HOB instance in the HOB list. Each HOB describes the corresponding CPU index range. The plan is to create gMpInformationHob2Guid in CpuMpPei module(implemented in next commit). Then PiSmmCpuDxeSmm and other MM_STANDALONE modules can consume the hob. This can avoid calling MpService Protocol in PiSmmCpuDxeSmm. Also the issue that one gMpInformationHobGuid might be not enough when CPU number is 1~2000 or bigger can be solved. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Get processor extended informationWu, Jiaxin2023-12-081-0/+10
| | | | | | | | | | | | | | | | | This patch is to extend SmmAddProcessor function to get processor extended information. It's to complete commit 1fadd18d. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231115111553.6592-3-jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/BaseXApicLib: Fix CPUID_V2_EXTENDED_TOPOLOGY detectionWu, Jiaxin2023-12-081-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is to complete 170d4ce8, sync the change to BaseXApicLib. Checking the max cpuid leaf is not enough to figure whenever CPUID_V2_EXTENDED_TOPOLOGY is supported. Intel SDM says: Software must detect the presence of CPUID leaf 1FH by verifying (a) the highest leaf index supported by CPUID is >= 1FH, and (b) CPUID.1FH:EBX[15:0] reports a non-zero value. The same is true for CPUID leaf 0BH. This patch adds the EBX check to GetProcessorLocation2ByApicId(). The patch also fixes the existing check in GetProcessorLocationByApicId() to be in line with the spec by looking at bits 15:0. The comments are updated with a quote from the Intel SDM. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Message-Id: <20231115111553.6592-2-jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Backup and Restore MSR IA32_U_CET in SMI handler.Sheng Wei2023-12-072-0/+30
| | | | | | | | | | | | | | | | | | OS may enable CET-IBT feature by set MSR IA32_U_CET.bit2. If IA32_U_CET.bit2 is set, CPU is in WAIT_FOR_ENDBRANCH state and the next assemble code is not ENDBR, it will trigger #CP exception when set CR4.CET bit. SMI handler needs to backup MSR IA32_U_CET and clear MSR IA32_U_CET before set CR4.CET bit, And SMI handler needs to restore MSR IA32_U_CET when exit SMI handler. Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Only change CR4.CET bit for enable and disable CET.Sheng Wei2023-12-072-6/+14
| | | | | | | | | | Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Use CET macro definitions in Cet.inc for SmiEntry.nasm files.Sheng Wei2023-12-072-29/+4
| | | | | | | | | | Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Use macro CR4_CET_BIT to replace hard code value in Cet.nasm.Sheng Wei2023-12-072-6/+8
| | | | | | | | | | Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Add macro definitions for CET feature for NASM files.Sheng Wei2023-12-071-0/+26
| | | | | | | | | | Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/CpuMpPei: Use CpuPageTableLib to set memory attribute.Zhiguang Liu2023-12-061-248/+69
| | | | | | | | | | | | | | Currently, there are code to set memory attribute in CpuMpPei module. However, the code doesn't handle the case of 5 level paging. Use the CpuPageTableLib to set memory attribute for two purpose: 1. Add 5 level paging support 2. Clean up code Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiCpuPkg/CpuPageTableLib/TestCase: Refine test case for PAE paging.Zhiguang Liu2023-12-062-4/+34
| | | | | | | | | | | | Refine test case: 1. Check PAE paging reserved bits is zero. 2. Set stack as random value. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiCpuPkg/CpuPageTableLib: Init local variable before using it.Zhiguang Liu2023-12-061-3/+1
| | | | | | | | | | | | | The local variable OneOfPagingEntry is used before initialized, this may cause reserved bit in page table entry is set especially in PAE paging mode. The bug is random because it depends on the value in stack. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Use NonSmm BSP as default SMM BSP.Zhiguang Liu2023-11-291-0/+10
| | | | | | | | | | | | | | | | Currently, if BSP election is not enabled, will use Core0 as SMM BSP. However, Core0 does not always have the highest performance. So, we can used NonSmm BSP as default BSP. This will take effect in normal SMM init flow and S3 boot flow. In normal SMM flow, the code is executed before first SMI. In S3 flow, the code is executed in Non-SMM BSP's first SMI, where the gSmmCpuPrivate keeps the data from last boot. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiCpuPkg/MpInitLib: Copy SEV-ES save area pointer during APIC ID sortingTom Lendacky2023-11-281-1/+7
| | | | | | | | | | | | | | | | | With SEV-SNP, the SEV-ES save area for a vCPU should be unique to that vCPU. After commit 3323359a811a, the VMSA allocation was re-used, but when sorting the CPUs by APIC ID, the save area was not updated to follow the original CPU. Similar to the StartupApSignal address, the SevEsSaveArea address should be updated when sorting the CPUs. This does not cause an issue at this time because all APs are in HLT state and then are (re)started at the same time, with the same VMSA contents. However, this should be fixed to account for any change in future behavior. Fixes: 3323359a811a ("UefiCpuPkg/MpInitLib: Reuse VMSA allocation to ...") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Use AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leafTom Lendacky2023-11-281-1/+8
| | | | | | | | | | | | | The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input when returning CPUID information. However, the AsmCpuid() function does not zero out ECX before the CPUID instruction, so the input leaf is used as the sub-leaf for the CPUID request and returns erroneous/invalid CPUID data, since the intent of the request was to get data related to sub-leaf 0. Instead, use AsmCpuidEx() for the CPUID_EXTENDED_TOPOLOGY leaf. Fixes: d4d7c9ad5fe5 ("UefiCpuPkg/MpInitLib: use BSP to do extended ...") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Use Attribute From SMM MemoryAttributesTable if NonzeroTaylor Beebe2023-11-271-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PiSmmCore fetches the EFI memory map and calls SplitTable() to split each loaded image section into its own descriptor with EFI_MEMORY_XP marking data sections and EFI_MEMORY_RO marking code sections. The SMM MAT logic is almost identical to the DXE MAT logic but goes a step further and also updates the memory map descriptors which describe image code and data sections to be of type EfiRuntimeServicesCode and EfiRuntimeServicesData respectively. The consolidated MAT logic (present in the new ImagePropertiesRecordLib) more closely follows the DXE MAT logic which identifies image code sections by the presence of the attribute EFI_MEMORY_RO in the descriptor and image data sections by the presence of the attribute EFI_MEMORY_XP. Because of the flow choice of the consolidated MAT logic, the SMM MAT logic should just use the attributes from the table returned by SplitTable(). Additionally, the function EnforceMemoryMapAttribute() in the SMM MAT logic will ensure that the CODE and DATA memory types have the desired attributes so bisecting this patch series at this commit will still function as before. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MpInitLib: Update the comments of _CPU_MP_DATA.xieyuanh2023-11-272-6/+9
| | | | | | | | | | | | | | | | | | | | No functional changes in this patch. Updates the comments of _CPU_MP_DATA to delcared that duplications in CpuMpData are present to avoid to be direct accessed and comprehended in assembly code. CpuMpData: Intended for use in C code while ExchangeInfo are used in assembly code in this module. This patch deletes the unnecessary comments in CpuMpData, since CpuMpData is no longer responsible for passing information from PEI to DXE. Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com> Cc: Laszlo Ersek lersek@redhat.com Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 11:39:23 +0000