summaryrefslogtreecommitdiffstats
path: root/UefiCpuPkg
Commit message (Collapse)AuthorAgeFilesLines
* UefiCpuPkg/MpInitLib: Remove unused Lock from MP_CPU_EXCHANGE_INFORay Ni2021-03-085-15/+1
| | | | | | | | | | The Lock is no longer needed since "LOCK XADD" was used in MpFuncs.nasm for ApIndex atomic increment. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/MpInitLib: Use NASM struc to avoid hardcode offsetRay Ni2021-03-087-180/+193
| | | | | | | | | | In Windows environment, "dumpbin /disasm" is used to verify the disassembly before and after using NASM struc doesn't change. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Fix SMM stack offset is not correctedk2-stable202102Sheng Wei2021-03-023-4/+8
| | | | | | | | | | | | | | | | | | | | | | | In function InitGdt(), SmiPFHandler() and Gen4GPageTable(), it uses CpuIndex * mSmmStackSize to get the SMM stack address offset for multi processor. It misses the SMM Shadow Stack Size. Each processor will use mSmmStackSize + mSmmShadowStackSize in the memory. It should use CpuIndex * (mSmmStackSize + mSmmShadowStackSize) to get this SMM stack address offset. If mSmmShadowStackSize > 0 and multi processor enabled, it will get the wrong offset value. CET shadow stack feature will set the value of mSmmShadowStackSize. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3237 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: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Roger Feng <roger.feng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/CpuExceptionHandlerLib: Clear CET shadow stack token busy bitSheng Wei2021-03-027-3/+75
| | | | | | | | | | | | | | | | | | | | | | | | | If CET shadows stack feature enabled in SMM and stack switch is enabled. When code execute from SMM handler to SMM exception, CPU will check SMM exception shadow stack token busy bit if it is cleared or not. If it is set, it will trigger #DF exception. If it is not set, CPU will set the busy bit when enter SMM exception. So, the busy bit should be cleared when return back form SMM exception to SMM handler. Otherwise, keeping busy bit 1 will cause to trigger #DF exception when enter SMM exception next time. So, we use instruction SAVEPREVSSP, CLRSSBSY and RSTORSSP to clear the shadow stack token busy bit before RETF instruction in SMM exception. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3192 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: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Roger Feng <roger.feng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Use XADD to avoid lock acquire/releaseRay Ni2021-02-262-26/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When AP firstly wakes up, MpFuncs.nasm contains below logic to assign an unique ApIndex to each AP according to who comes first: ---ASM--- TestLock: xchg [edi], eax cmp eax, NotVacantFlag jz TestLock mov ecx, esi add ecx, ApIndexLocation inc dword [ecx] mov ebx, [ecx] Releaselock: mov eax, VacantFlag xchg [edi], eax ---ASM END--- "lock inc" cannot be used to increase ApIndex because not only the global ApIndex should be increased, but also the result should be stored to a local general purpose register EBX. This patch learns from the NASM implementation of InternalSyncIncrement() to use "XADD" instruction which can increase the global ApIndex and store the original ApIndex to EBX in one instruction. With this patch, OVMF when running in a 255 threads QEMU spends about one second to wakeup all APs. Original implementation needs more than 10 seconds. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg: Move MigrateGdt from DiscoverMemory to TempRamDone. (CVE-2019-11098)Guomin Jiang2021-02-045-46/+46
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1614 REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3160 The GDT still in flash with commit 60b12e69fb1c8c7180fdda92f008248b9ec83db1 after TempRamDone So move the action to TempRamDone event to avoid reading GDT from flash. Signed-off-by: Guomin Jiang <guomin.jiang@intel.com> 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> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/CpuCacheInfoLib: Support no enabled AP case in DxeLibLou, Yun2021-02-031-0/+7
| | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3195 Support system has no enabled AP case in DxeCpuCacheInfoLib. Otherwise, if the system only has 1 BSP without any enabled AP, UEFI POST hangs when invoking StartupAllAPs protocol because EFI_NOT_STARTED is returned. Signed-off-by: Jason Lou <yun.lou@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/CpuCacheInfoLib: Add MpService dependencyLou, Yun2021-02-034-10/+3
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3190 Add MpService dependency to enforce the executability of CpuCacheInfoLib. Signed-off-by: Jason Lou <yun.lou@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg: SmmCpuExceptionHandlerLib: Added StandaloneMm module supportKun Qin2021-02-011-1/+1
| | | | | | | | | | | | | | | This change of SmmCpuExceptionHandlerLib adds support for StandaloneMm components to allow x64 StandaloneMm environment setting up exception handlers. 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: Kun Qin <kun.q@outlook.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: CpuIo2Smm: Support of CpuIo driver under StandaloneMmKun Qin2021-02-013-0/+82
| | | | | | | | | | | | | | This change adds a new CpuIo driver instance for MM_STANDALONE type. The new driver entrypoint is implemented in a separate file to match the interface definition of MM_STANDALONE modules. 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: Kun Qin <kun.q@outlook.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: CpuIo2Smm: Abstract SMM specific functions into separate fileKun Qin2021-02-014-381/+421
| | | | | | | | | | | | | | | This change abstracts CpuIo2Smm driver entrypoint into separate file and moves functions/definitions that are not substantially specific to Traditional MM (SMM) into CpuIo2Mm.* in order to set ways for Standalone MM support in the future. 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: Kun Qin <kun.q@outlook.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: CpuIo2Smm: Move CpuIo2Smm driver to consume gMmstKun Qin2021-02-014-5/+6
| | | | | | | | | | | | | | This change replaced gSmst with gMmst to support broader compatibility under MM environment for CpuIo2Smm driver. 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: Kun Qin <kun.q@outlook.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Don't increase CpuCount in ApWakeupFunctionRay Ni2021-01-291-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3179 When BSP first time wakes all APs, each AP atomically increases CpuMpData->CpuCount and CpuMpData->FinishedCount. Each AP atomically increases CpuMpData->NumApsExecuting in early assembly code and decreases it before it enters to HLT or MWAIT state. Putting them together, the 3 variables are changed in the following order: 1. NumApsExecuting++ // in assembly 2. CpuCpunt++ 4. FinishedCount++ 3. NumApsExecuting-- // in C BSP waits for a certain timeout and then polls NumApsExecuting until it drops to zero. It assumes all APs are waken up concurrently and NumApsExecuting only drops to zero when all APs have checked in. Then it additionally waits for FinishedCount == CpuCount - 1. (FinishedCount doesn't include BSP while CpuCount includes BSP.) There is no need to additionally wait for FinishedCount == CpuCount - 1 because when NumApsExecuting == 0, the number of increament of FinishedCount and CpuCount should equal. This patch simplifies the code to remove "CpuCount++" in ApWakeupFunction() and assigns FinishedCount + 1 to CpuCount after WakeUpAP(). Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* MdePkg/Cpuid.h: Change and add some macro definitions.Lou, Yun2021-01-261-1/+1
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3105 Change and add some macro definitions about CPUID_HYBRID_INFORMATION Leaf(1Ah). Signed-off-by: Jason Lou <yun.lou@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/Library/MpInitLib: Fix AP VolatileRegisters race conditionMichael D Kinney2021-01-261-13/+18
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3182 Fix the order of operations in ApWakeupFunction() when PcdCpuApLoopMode is set to HLT mode that uses INIT-SIPI-SIPI to wake APs. In this mode, volatile state is restored and saved each time a INIT-SIPI-SIPI is sent to an AP to request a function to be executed on the AP. When the function is completed the volatile state of the AP is saved. However, the counters NumApsExecuting and FinishedCount are updated before the volatile state is saved. This allows for a race condition window for the BSP that is waiting on these counters to request a new INIT-SIPI-SIPI before all the APs have completely saved their volatile state. The fix is to save the AP volatile state before updating the NumApsExecuting and FinishedCount counters. Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* UefiCpuPkg/CpuMp: Fix hang when StackGuard is enabled in 16-core cpuRay Ni2021-01-223-9/+7
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3167 When StackGuard is enabled, the CpuMp driver allocates known good stacks for all CPUs for DF# and PF# exceptions. It uses AllocatePool to do so. The size needed equals to 64KB = StackSize (2K) * ExceptionNumber (2) * NumberOfProcessors (16) However, AllocatePool max allocation size is less than 64K. To fix the issue, AllocatePages() is used. 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 RegisterCpuFeaturesLib: NumberOfCpus may be uninitializedZeng, Star2021-01-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | NumberOfCpus local variable in GetAcpiCpuData will be uninitialized when CpuS3DataDxe runs before DxeRegisterCpuFeaturesLib (linked by CpuFeaturesDxe) because there is no code to initialize it at (AcpiCpuData != NULL) execution path. The issue is exposed after cefad282fb31aff3e1a6dcbd368cbbffc3fce900 and 38ee7bafa72f58982f99ac6f61eef160f80bad69. There was negligence in that code review. One further topic may be "Could EDK2 CI be enhanced to catch this kind of uninitialized local variable case?". :) This patch fixes this regression issue. 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> Message-Id: <20210121093944.1621-1-star.zeng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuS3DataDxe: do not allocate useless register tablesLaszlo Ersek2021-01-201-32/+0
| | | | | | | | | | | | | | | | | | | | | | | | | CpuS3DataDxe allocates the "RegisterTable" and "PreSmmInitRegisterTable" arrays in ACPI_CPU_DATA just so every processor in the system can have its own empty register table, matched by APIC ID. This has never been useful in practice. Given commit e992cc3f4859 ("UefiCpuPkg PiSmmCpuDxeSmm: Reduce SMRAM consumption in CpuS3.c", 2021-01-11), simply leave both "AcpiCpuData->RegisterTable" and "AcpiCpuData->PreSmmInitRegisterTable" initialized to the zero address. This simplifies the driver, and saves both normal RAM (boot services data type memory) and -- in PiSmmCpuDxeSmm -- SMRAM. Cc: Eric Dong <eric.dong@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3159 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Message-Id: <20210119155440.2262-4-lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/AcpiCpuData: update comments on register table fieldsLaszlo Ersek2021-01-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | After commit e992cc3f4859 ("UefiCpuPkg PiSmmCpuDxeSmm: Reduce SMRAM consumption in CpuS3.c", 2021-01-11), it is valid for a CPU S3 Data DXE Driver to set "ACPI_CPU_DATA.PreSmmInitRegisterTable" and/or "ACPI_CPU_DATA.RegisterTable" to 0, in case none of the CPUs needs a register table of the corresponding kind, during S3 resume. Document this fact in the "UefiCpuPkg/Include/AcpiCpuData.h" header file. Cc: Eric Dong <eric.dong@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3159 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210119155440.2262-3-lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/CpuFeature: Don't assume CpuS3DataDxe alloc RegisterTableRay Ni2021-01-201-33/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are lots of fields in ACPI_CPU_DATA structure while only followings are accessed by CpuFeature infra: * NumberOfCpus * PreSmmInitRegisterTable // pointer * RegisterTable // pointer * CpuStatus * ApLocation // pointer So it's possible that an implementation of CpuS3DataDxe doesn't allocate memory for PreSmmInitRegisterTable/RegisterTable/ApLocation. This patch handles the case when CpuS3DataDxe doesn't allocate memory for PreSmmInitRegisterTable/RegisterTable. Cc: Eric Dong <eric.dong@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3159 Signed-off-by: Ray Ni <ray.ni@intel.com> [lersek@redhat.com: update CC list, add BZ reference, add my S-o-b] [lersek@redhat.com: deal with RegisterTable and PreSmmInitRegisterTable being zero independently of each other; replacing the ASSERT()] Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210119155440.2262-2-lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/CpuCacheInfoLib: Add new CpuCacheInfoLib.Lou, Yun2021-01-1910-0/+1023
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3105 This new library uses a platform agnostic algorithm to get CPU cache information. It provides user with an API(GetCpuCacheInfo) to get detailed CPU cache information by each package, each core type included in this package, and each cache level & type. This library can be used by code that produces SMBIOS_TABLE_TYPE7 SMBIOS table. Signed-off-by: Jason Lou <yun.lou@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/CpuDxe: Fix boot errorGuo Dong2021-01-121-5/+3
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3084 When DXE drivers are dispatched above 4GB memory in 64bit mode, the address setCodeSelectorLongJump in stack will be override by parameter. Jump to Qword is not supported by some processors. So use "o64 retf" instead. Signed-off-by: Guo Dong <guo.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Fix a hang in above 4GB caseGuo Dong2021-01-121-4/+4
| | | | | | | | | | | | This patch fixed the hang in UEFICpuPkg when it is dispatched above 4GB. In UEFI BIOS case CpuInfoInHob is provided to DXE under 4GB from PEI. When using UEFI payload and bootloaders, CpuInfoInHob will be allocated above 4GB since it is not provided from bootloader. so we need update the code to make sure this hob could be accessed correctly in this case. Signed-off-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg PiSmmCpuDxeSmm: Reduce SMRAM consumption in CpuS3.cZeng, Star2021-01-111-17/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes two refinements to reduce SMRAM consumption in CpuS3.c. 1. Only do CopyRegisterTable() when register table is not empty, IsRegisterTableEmpty() is created to check whether the register table is empty or not. Take empty PreSmmInitRegisterTable as example, about 24K SMRAM consumption could be reduced when mAcpiCpuData.NumberOfCpus=1024. sizeof (CPU_REGISTER_TABLE) = 24 mAcpiCpuData.NumberOfCpus = 1024 = 1K mAcpiCpuData.NumberOfCpus * sizeof (CPU_REGISTER_TABLE) = 24K 2. Only copy table entries buffer instead of whole buffer. AllocatedSize in SourceRegisterTableList is the whole buffer size. Actually, only the table entries buffer needs to be copied, and the size is TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY). Take AllocatedSize=0x1000=4096, TableLength=100 and NumberOfCpus=1024 as example, about 1696K SMRAM consumption could be reduced. sizeof (CPU_REGISTER_TABLE_ENTRY) = 24 TableLength = 100 TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY) = 2400 AllocatedSize = 0x1000 = 4096 AllocatedSize - TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY) = 4096 - 2400 = 1696 NumberOfCpus = 1024 = 1K NumberOfCpus * (AllocatedSize - TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY)) = 1696K This patch also corrects the CopyRegisterTable() function description. Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210111015419.28368-1-star.zeng@intel.com>
* Revert "UefiCpuPkg/CpuDxe: Fix boot error"Laszlo Ersek2020-12-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit cee5b0441af39dd6f76cc4e0447a1c7f788cbb00. Commit cee5b0441af3 ("UefiCpuPkg/CpuDxe: Fix boot error", 2020-12-08) breaks CpuDxe (and with it, OVMF boot) on AMD processors. AMD processors cannot do far jumps to 64-bit targets, as documented in the AMD64 Architecture Programmer's Manual. Revert the patch until a RETFQ-based substitute is posted. Cc: Eric Dong <eric.dong@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Thomas Lendacky <thomas.lendacky@amd.com> Ref: https://edk2.groups.io/g/devel/message/68597 Ref: https://www.redhat.com/archives/edk2-devel-archive/2020-December/msg00493.html Reported-by: Thomas Lendacky <thomas.lendacky@amd.com> Ref: https://edk2.groups.io/g/devel/message/68832 Ref: https://www.redhat.com/archives/edk2-devel-archive/2020-December/msg00737.html Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201217085055.15131-1-lersek@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3121 [lersek@redhat.com: add BZ link]
* UefiCpuPkg/CpuFeature: reduce time complexty to calc CpuInfo.FirstRay Ni2020-12-141-49/+47
| | | | | | | | | | | | | | | | | | | | | | CpuInfo.First stores whether the current thread belongs to the first package in the platform, first core in a package, first thread in a core. But the time complexity of original algorithm to calculate the CpuInfo.First is O (n) * O (p) * O (c). n: number of processors p: number of packages c: number of cores per package The patch trades time with space by storing the first package, first core per package, first thread per core in an array. The time complexity becomes O (n). 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: Yun Lou <yun.lou@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg RegisterCpuFeaturesLib: Use AllocatePages() for InitOrderStar Zeng2020-12-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | The required buffer size for InitOrder will be 96K when NumberOfCpus=1024. sizeof (CPU_FEATURES_INIT_ORDER) = 96 NumberOfCpus = 1024 = 1K sizeof (CPU_FEATURES_INIT_ORDER) * NumberOfCpus = 96K AllocateZeroPool() will call to PeiServicesAllocatePool() which will use EFI_HOB_MEMORY_POOL to management memory pool. EFI_HOB_MEMORY_POOL.Header.HobLength is UINT16 type, so there is no way for AllocateZeroPool() to allocate > 64K memory. So AllocateZeroPool() could not be used anymore for the case above or even bigger required buffer size. This patch updates the code to use AllocatePages() instead of AllocateZeroPool() to allocate buffer for InitOrder. Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/SmmCpuFeaturesLib: Add Tiger Lake supportGuo Dong2020-12-081-1/+2
| | | | | | | Add Tiger Lake ModelId support in the SMM CPU feature lib. Signed-off-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/CpuDxe: Fix boot errorGuo Dong2020-12-081-2/+2
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3084 When DXE drivers are dispatched above 4GB memory and the system is already in 64bit mode, the address setCodeSelectorLongJump in stack will be override by parameter. so change to use 64bit address and jump to qword address. Signed-off-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/Feature: Support different thread count per coreRay Ni2020-12-043-83/+119
| | | | | | | | | | | | | | | | | Today's code assumes every core contains the same number of threads. It's not always TRUE for certain model. Such assumption causes system hang when thread count per core is different and there is core or package dependency between CPU features (using CPU_FEATURE_CORE_BEFORE/AFTER, CPU_FEATURE_PACKAGE_BEFORE/AFTER). The change removes such assumption by calculating the actual thread count per package and per core. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Yun Lou <yun.lou@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Reflect page table depth with page table addressSheng Wei2020-11-184-37/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to get page table base, if mInternalCr3 is zero, it will use the page table from CR3, and reflect the page table depth by CR4 LA57 bit. If mInternalCr3 is non zero, it will use the page table from mInternalCr3 and reflect the page table depth of mInternalCr3 at same time. In the case of X64, we use m5LevelPagingNeeded to reflect the depth of the page table. And in the case of IA32, it will not the page table depth information. This patch is a bug fix when enable CET feature with 5 level paging. The SMM page tables are allocated / initialized in PiCpuSmmEntry(). When CET is enabled, PiCpuSmmEntry() must further modify the attribute of shadow stack pages. This page table is not set to CR3 in PiCpuSmmEntry(). So the page table base address is set to mInternalCr3 for modifty the page table attribute. It could not use CR4 LA57 bit to reflect the page table depth for mInternalCr3. So we create a architecture-specific implementation GetPageTable() with 2 output parameters. One parameter is used to output the page table address. Another parameter is used to reflect if it is 5 level paging or not. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3015 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: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Correct the Cr3 typoSheng Wei2020-11-181-5/+5
| | | | | | | | | | | | | | | | Change the variable name from mInternalGr3 to mInternalCr3. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3015 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: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: For SEV-ES guest, set stack based on processor numberTom Lendacky2020-11-101-1/+6
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 Set the SEV-ES reset stack address for an AP based on the processor number instead of the APIC ID in case the APIC IDs are not zero-based and densely packed/enumerated. This will ensure an AP reset stack address does not get set outside of the AP reset stack memory allocation. 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> Acked-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <24866de07d2a954dec71df70972f1851273020d8.1604685192.git.thomas.lendacky@amd.com>
* UefiCpuPkg, OvmfPkg: Disable interrupts when using the GHCBTom Lendacky2020-11-104-17/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The QemuFlashPtrWrite() flash services runtime uses the GHCB and VmgExit() directly to perform the flash write when running as an SEV-ES guest. If an interrupt arrives between VmgInit() and VmgExit(), the Dr7 read in the interrupt handler will generate a #VC, which can overwrite information in the GHCB that QemuFlashPtrWrite() has set. This has been seen with the timer interrupt firing and the CpuExceptionHandlerLib library code, UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ Xcode5ExceptionHandlerAsm.nasm and ExceptionHandlerAsm.nasm reading the Dr7 register while QemuFlashPtrWrite() is using the GHCB. In general, it is necessary to protect the GHCB whenever it is used, not just in QemuFlashPtrWrite(). Disable interrupts around the usage of the GHCB by modifying the VmgInit() and VmgDone() interfaces: - VmgInit() will take an extra parameter that is a pointer to a BOOLEAN that will hold the interrupt state at the time of invocation. VmgInit() will get and save this interrupt state before updating the GHCB. - VmgDone() will take an extra parameter that is used to indicate whether interrupts are to be (re)enabled. Before exiting, VmgDone() will enable interrupts if that is requested. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 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: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <c326a4fd78253f784b42eb317589176cf7d8592a.1604685192.git.thomas.lendacky@amd.com>
* UefiCpuPkg/MpInitLib: Set the SW exit fields when performing VMGEXITTom Lendacky2020-11-101-0/+6
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bits for the software exit information fields when performing a VMGEXIT (SwExitCode, SwExitInfo1, SwExitInfo2). Fixes: 20da7ca42a33d3ef767ce4129f11496af7f67c9f 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> Acked-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <6e11dd7e161bddeacc3fb4817467cef24510c31c.1604685192.git.thomas.lendacky@amd.com>
* UefiCpuPkg/VmgExitLib: Add interfaces to set/read GHCB ValidBitmap bitsTom Lendacky2020-11-102-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 In upcoming patches, the setting of the bits in the GHCB ValidBitmap will be performed in multiple places. In order to reduce code duplication, add an interface, VmgSetOffsetValid(), to VmgExitLib library to perform this function. Also, to keep management of the ValidBitmap within the library, add an inteface, VmgIsOffsetValid(), to return whether the bit in the ValidBitmap is set for a specified offset. The new VmgSetOffsetValid() function is a VOID function and will be an empty function in the VmgExitLibNull implementation of the VmgExitLib library. The new VmgIsOffsetValid() function returns a BOOLEAN to indicate if the offset is valid. This will always return FALSE in the VmgExitLibNull implementation of the VmgExitLib library. 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> Acked-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <0bcb2373f8c6e0171ae277d3d7c2eb284621355e.1604685192.git.thomas.lendacky@amd.com>
* UefiCpuPkg/MpInitLib: Reduce reset vector memory pressureTom Lendacky2020-10-191-19/+17
| | | | | | | | | | | | | | | | The AP reset vector stack allocation is only required if running as an SEV-ES guest. Since the reset vector allocation is below 1MB in memory, eliminate the requirement for bare-metal systems and non SEV-ES guests to allocate the extra stack area, which can be large if the PcdCpuMaxLogicalProcessorNumber value is large, and also remove the CPU_STACK_ALIGNMENT alignment. Fixes: 7b7508ad784d ("UefiCpuPkg: Allow AP booting under SEV-ES") Cc: Garrett Kirkendall <garrett.kirkendall@amd.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <21345cdbc906519558202b3851257ca07b9239ba.1600884239.git.thomas.lendacky@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: supply missing space character after "PcdGet32"]
* UefiCpuPkg/RegisterCpuFeaturesLib: Support MpServices2 only case.Chasel Chiu2020-09-143-44/+28
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2883 MpServices Ppi can be replaced by MpServices2 Ppi and MpServices2 Ppi is mandatory for RegisterCpuFeaturesLib functionality, basing on this we can drop MpServices Ppi usage from the library and the constraint that both Ppis must be installed. 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: Nate DeSimone <nathaniel.l.desimone@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Always initialize the DoDecrement variableTom Lendacky2020-08-241-3/+1
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2901 The DoDecrement variable in ApWakeupFunction () wasn't always being initialized. Update the code to always fully initialize it. 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: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <76a9f18992475b915e5f8457704676067210cacf.1597935198.git.thomas.lendacky@amd.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Tested-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/UefiCpuPkg.ci.yaml: Add configuration for Ecc checkShenglei Zhang2020-08-171-0/+12
| | | | | | | | | | | | | | Add configuration ExceptionList and IgnoreFiles for package config files. So users can rely on this to ignore some Ecc issues. 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> Acked-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* UefiCpuPkg/MpInitLib: Prepare SEV-ES guest APs for OS useTom Lendacky2020-08-174-18/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Before UEFI transfers control to the OS, it must park the AP. This is done using the AsmRelocateApLoop function to transition into 32-bit non-paging mode. For an SEV-ES guest, a few additional things must be done: - AsmRelocateApLoop must be updated to support SEV-ES. This means performing a VMGEXIT AP Reset Hold instead of an MWAIT or HLT loop. - Since the AP must transition to real mode, a small routine is copied to the WakeupBuffer area. Since the WakeupBuffer will be used by the AP during OS booting, it must be placed in reserved memory. Additionally, the AP stack must be located where it can be accessed in real mode. - Once the AP is in real mode it will transfer control to the destination specified by the OS in the SEV-ES AP Jump Table. The SEV-ES AP Jump Table address is saved by the hypervisor for the OS using the GHCB VMGEXIT AP Jump Table exit code. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Allow AP booting under SEV-ESTom Lendacky2020-08-1711-15/+738
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Typically, an AP is booted using the INIT-SIPI-SIPI sequence. This sequence is intercepted by the hypervisor, which sets the AP's registers to the values requested by the sequence. At that point, the hypervisor can start the AP, which will then begin execution at the appropriate location. Under SEV-ES, AP booting presents some challenges since the hypervisor is not allowed to alter the AP's register state. In this situation, we have to distinguish between the AP's first boot and AP's subsequent boots. First boot: Once the AP's register state has been defined (which is before the guest is first booted) it cannot be altered. Should the hypervisor attempt to alter the register state, the change would be detected by the hardware and the VMRUN instruction would fail. Given this, the first boot for the AP is required to begin execution with this initial register state, which is typically the reset vector. This prevents the BSP from directing the AP startup location through the INIT-SIPI-SIPI sequence. To work around this, the firmware will provide a build time reserved area that can be used as the initial IP value. The hypervisor can extract this location value by checking for the SEV-ES reset block GUID that must be located 48-bytes from the end of the firmware. The format of the SEV-ES reset block area is: 0x00 - 0x01 - SEV-ES Reset IP 0x02 - 0x03 - SEV-ES Reset CS Segment Base[31:16] 0x04 - 0x05 - Size of the SEV-ES reset block 0x06 - 0x15 - SEV-ES Reset Block GUID (00f771de-1a7e-4fcb-890e-68c77e2fb44e) The total size is 22 bytes. Any expansion to this block must be done by adding new values before existing values. The hypervisor will use the IP and CS values obtained from the SEV-ES reset block to set as the AP's initial values. The CS Segment Base represents the upper 16 bits of the CS segment base and must be left shifted by 16 bits to form the complete CS segment base value. Before booting the AP for the first time, the BSP must initialize the SEV-ES reset area. This consists of programming a FAR JMP instruction to the contents of a memory location that is also located in the SEV-ES reset area. The BSP must program the IP and CS values for the FAR JMP based on values drived from the INIT-SIPI-SIPI sequence. Subsequent boots: Again, the hypervisor cannot alter the AP register state, so a method is required to take the AP out of halt state and redirect it to the desired IP location. If it is determined that the AP is running in an SEV-ES guest, then instead of calling CpuSleep(), a VMGEXIT is issued with the AP Reset Hold exit code (0x80000004). The hypervisor will put the AP in a halt state, waiting for an INIT-SIPI-SIPI sequence. Once the sequence is recognized, the hypervisor will resume the AP. At this point the AP must transition from the current 64-bit long mode down to 16-bit real mode and begin executing at the derived location from the INIT-SIPI-SIPI sequence. Another change is around the area of obtaining the (x2)APIC ID during AP startup. During AP startup, the AP can't take a #VC exception before the AP has established a stack. However, the AP stack is set by using the (x2)APIC ID, which is obtained through CPUID instructions. A CPUID instruction will cause a #VC, so a different method must be used. The GHCB protocol supports a method to obtain CPUID information from the hypervisor through the GHCB MSR. This method does not require a stack, so it is used to obtain the necessary CPUID information to determine the (x2)APIC ID. The new 16-bit protected mode GDT entry is used in order to transition from 64-bit long mode down to 16-bit real mode. A new assembler routine is created that takes the AP from 64-bit long mode to 16-bit real mode. This is located under 1MB in memory and transitions from 64-bit long mode to 32-bit compatibility mode to 16-bit protected mode and finally 16-bit real mode. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MpInitLib: Add CPU MP data flag to indicate if SEV-ES is enabledTom Lendacky2020-08-174-0/+5
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 When starting APs in an SMP configuration, the AP needs to know if it is running as an SEV-ES guest in order to assign a GHCB page. Add a field to the CPU_MP_DATA structure that will indicate if SEV-ES is enabled. This new field is set during MP library initialization with the PCD value PcdSevEsIsEnabled. This flag can then be used to determine if SEV-ES is enabled. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Add a 16-bit protected mode code segment descriptorTom Lendacky2020-08-173-6/+15
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 A hypervisor is not allowed to update an SEV-ES guests register state, so when booting an SEV-ES guest AP, the hypervisor is not allowed to set the RIP to the guest requested value. Instead, an SEV-ES AP must be transition from 64-bit long mode to 16-bit real mode in response to an INIT-SIPI-SIPI sequence. This requires a 16-bit code segment descriptor. For PEI, create this descriptor in the reset vector GDT table. For DXE, create this descriptor from the newly reserved entry at location 0x28. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Create an SEV-ES workarea PCDTom Lendacky2020-08-172-0/+16
| | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Create an SEV-ES workarea PCD. This PCD will be used for BSP communication during SEC and for AP startup during PEI and DXE phases, the latter is the reason for creating it in the UefiCpuPkg. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuExceptionHandler: Add base support for the #VC exceptionTom Lendacky2020-08-1710-2/+86
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Add base support to handle #VC exceptions. Update the common exception handlers to invoke the VmgExitHandleVc () function of the VmgExitLib library when a #VC is encountered. A non-zero return code will propagate to the targeted exception handler. Under SEV-ES, a DR7 read or write intercept generates a #VC exception. To avoid exception recursion, a #VC exception will not try to read and push the actual debug registers into the EFI_SYSTEM_CONTEXT_X64 struct and instead push zeroes. The #VC exception handler does not make use of the debug registers from the saved context and the exception processing exit code does not attempt to restore the debug register values. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Implement library support for VMGEXITTom Lendacky2020-08-166-0/+271
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 To support handling #VC exceptions and issuing VMGEXIT instructions, create a library with functions that can be used to perform these #VC/VMGEXIT related operations. This includes functions for: - Handling #VC exceptions - Preparing for and issuing a VMGEXIT - Performing MMIO-related write operations to support flash emulation - Performing AP related boot opeations The base functions in this driver will not do anything and will return an error if a return value is required. It is expected that other packages (like OvmfPkg) will create a version of the library to fully support an SEV-ES guest. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Create PCD to be used in support of SEV-ESTom Lendacky2020-08-162-0/+9
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 A new dynamic UefiCpuPkg PCD is needed to support SEV-ES under OVMF: - PcdSevEsIsEnabled: BOOLEAN value used to indicate if SEV-ES is enabled Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MtrrLibUnitTest: Change to use static array for CI testRay Ni2020-08-125-12/+5126
| | | | | | | | | | | | | | | | | | | | | | | | | | The unit test app supports running in 3 mode: 1. MtrrLibUnitTest generate-random-numbers <path to MtrrLib/UnitTest/RandomNumber.c> <random-number count> It generates random numbers and writes to RandomNumber.c. 2. MtrrLibUnitTest [<iterations>] It tests MtrrLib APIs using configurations generated from static numbers generated by mode #1. This is the default execution mode running in CI environment. 3. MtrrLibUnitTest <iterations> random It tests MtrrLib APIs using configurations generated from random numbers. This is what developers can use to test MtrrLib for regressions. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ming Shao <ming.shao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
* UefiCpuPkg/MtrrLib/UnitTest: Add host based unit testRay Ni2020-08-126-1/+2325
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add host based unit tests for the MtrrLib services. The BaseLib services AsmCpuid(), AsmReadMsr64(), and AsmWriteMsr64() are hooked and provide simple emulation of the CPUID leafs and MSRs required by the MtrrLib to run as a host based unit test. Test cases are developed for each of the API. For the most important APIs MtrrSetMemoryAttributesInMtrrSettings() and MtrrSetMemoryAttributeInMtrrSettings(), random inputs are generated and fed to the APIs to make sure the implementation is good. The test application accepts an optional parameter which specifies how many iterations of feeding random inputs to the two APIs. The overall number of test cases increases when the iteration increases. Default iteration is 10 when no parameter is specified. Signed-off-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Ming Shao <ming.shao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ming Shao <ming.shao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-21 15:42:16 +0000