summaryrefslogtreecommitdiffstats
path: root/UefiCpuPkg
Commit message (Collapse)AuthorAgeFilesLines
* UefiCpuPkg/Microcode: Fix incorrect checksum issue for extended tableChen A Chen2019-02-211-9/+73
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020 The following Microcode payload format is define in SDM spec. Payload: |MicrocodeHeader|MicrocodeBinary|ExtendedHeader|ExtendedTable|. When we verify the CheckSum32 with ExtendedTable, we should use the fields of ExtendedTable to replace corresponding fields in MicrocodeHeader, and then calculate the CheckSum32 with MicrocodeHeader+MicrocodeBinary. This patch already verified on ICL platform. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chen A Chen <chen.a.chen@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Zhang Chao B <chao.b.zhang@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/SecCore: Wrong Debug Information for SecCoreChasel, Chiu2019-02-203-36/+54
| | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1533 When SecCore and PeiCore in different FV, current implementation still assuming SecCore and PeiCore are in the same FV. To fix this issue 2 FVs will be input parameters for FindAndReportEntryPoints () and SecCore and PeiCore will be found in each FV and correct debug information will be reported. Test: Booted with internal platform successfully. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MtrrLib: Fix a bug that may wrongly set memory <1MB to UCRuiyu Ni2019-02-191-41/+18
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1481 Today's MtrrLib contains a bug, for example: when the original cache setting is WB for [0xF_0000, 0xF_8000) and, a new request to set [0xF_0000, 0xF_4000) to WP, the cache setting for [0xF_4000, 0xF_8000) is reset to UC. The reason is when MtrrLibSetBelow1MBMemoryAttribute() is called the WorkingFixedSettings doesn't contain the actual MSR value stored in hardware, but when writing the fixed MTRRs, the code logic assumes WorkingFixedSettings contains the actual MSR value. The new fix is to change MtrrLibSetBelow1MBMemoryAttribute() to calculate the correct ClearMasks[] and OrMasks[], and use them directly when writing the fixed MTRRs. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
* UefiCpuPkg/SecCore: Support EFI_PEI_CORE_FV_LOCATION_PPIChasel, Chiu2019-02-151-4/+4
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524 Previous commit 373c2c5b888d029d7103206556bb85f33d980569, missed one comment change that should be fixed. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/SecCore: Support EFI_PEI_CORE_FV_LOCATION_PPIChasel, Chiu2019-02-153-8/+33
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524 EFI_PEI_CORE_FV_LOCATION_PPI may be passed by platform when PeiCore not in BFV so SecCore has to search PeiCore either from the FV location provided by EFI_PEI_CORE_FV_LOCATION_PPI or from BFV. Test: Verified on internal platform and booting successfully. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Replace AcquireSpinLock.Eric Dong2019-01-151-2/+7
| | | | | | | | | | | | | | | In AcquireSpinLock function, it may call GetPerformanceCounter which final calls PeiService table. This code may also been used by AP but AP should not calls PeiService. This patch update code to avoid use AcquireSpinLock function. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1411 Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/S3Resume2Pei: check 64BIT_WAKE_F in FACS.OSPMFlags.Eric Dong2019-01-151-3/+3
| | | | | | | | | | | | | | | | | | | ((Facs->Flags & EFI_ACPI_4_0_OSPM_64BIT_WAKE__F) != 0)) In above code, Facs->OspmFlags should be used instead. EFI_ACPI_4_0_OSPM_64BIT_WAKE__F is a bit in OSPM Enabled Firmware Control Structure Flags field, not in Firmware Control Structure Feature Flags. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1430 Cc: Aleksiy <oleksiyy@ami.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Avoid AP calls PeiService.Eric Dong2019-01-144-78/+99
| | | | | | | | | | | | | | | | | | | | | | | | | V3: Define union to specify the ppi or protocol. V2: 1. Initialize CpuFeaturesData->MpService in CpuInitDataInitialize and make this function been called at the begin of the initialization. 2. let all other functions use CpuFeaturesData->MpService install of locate the protocol itself. V1: GetProcessorIndex function calls GetMpPpi to get the MP Ppi. Ap will calls GetProcessorIndex function which final let AP calls PeiService. This patch avoid GetProcessorIndex call PeiService. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1411 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Enhance debug message.Eric Dong2019-01-141-6/+11
| | | | | | | | | | Enhance debug message format to let them easy to read. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1411 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Merge StuffRsb.inc files into one in UefiCpuPkg/IncludeHao Wu2019-01-0212-174/+10
| | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1091 Previously, when compiling NASM source files, BaseTools did not support including files outside of the NASM source file directory. As a result, we duplicated multiple copies of "StuffRsb.inc" files in UefiCpuPkg. Those INC files contain the common logic to stuff the Return Stack Buffer and are identical. After the fix of BZ 1085: https://bugzilla.tianocore.org/show_bug.cgi?id=1085 The above support was introduced. Thus, this commit will merge all the StuffRsb.inc files in UefiCpuPkg into one file. The merged file will be named 'StuffRsbNasm.inc' and be placed under folder UefiCpuPkg/Include/. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Update to consume SpeculationBarrierHao Wu2018-12-251-3/+3
| | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417 Since BaseLib API AsmLfence() is a x86 arch specific API and should be avoided using in generic codes, this commit replaces the usage of AsmLfence() with arch-generic API SpeculationBarrier(). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/CpuExceptionHandlerLib: Fix spelling issueMike Maslenkin2018-12-215-5/+5
| | | | | | | | | | *Excpetion* should be *Exception* Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com> CC: Eric Dong <eric.dong@intel.com> CC: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/Cpuid: Add code to support new definition.Eric Dong2018-12-101-5/+141
| | | | | | | | | | | Add code to support new definitions added in SDM 2018'11 version. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/Cpuid.h: Sync CPUID definition to latest SDM.Eric Dong2018-12-101-23/+597
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update CPUID definition to follow SDM 2018'11 version, changes Include: 1. Add new fields to the existed data structure, impact CPUIDs include: 1. CPUID_THERMAL_POWER_MANAGEMENT 0x06 CPUID_THERMAL_POWER_MANAGEMENT_EAX 2. CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS 0x07 CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_EBX CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_ECX 3. CPUID_ARCHITECTURAL_PERFORMANCE_MONITORING 0x0A CPUID_ARCHITECTURAL_PERFORMANCE_MONITORING_EDX 4. CPUID_EXTENDED_STATE 0x0D CPUID_EXTENDED_STATE_MAIN_LEAF_EAX CPUID_EXTENDED_STATE_SUB_LEAF_ECX 5. CPUID_INTEL_RDT_ALLOCATION 0x10 CPUID_INTEL_RDT_ALLOCATION_ENUMERATION_SUB_LEAF_EBX 6. CPUID_INTEL_SGX 0x12 CPUID_INTEL_SGX_CAPABILITIES_0_SUB_LEAF_EAX 2. Add new data structures which not existed before, impact CPUID includes: 1. CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS 0x07 CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_EDX 3. Remove fields which defined before, impact CPUID includes: 1. CPUID_INTEL_RDT_ALLOCATION 0x10 CPUID_INTEL_RDT_ALLOCATION_L3_CACHE_SUB_LEAF 0x01 CPUID_INTEL_RDT_ALLOCATION_L3_CACHE_SUB_LEAF_ECX 4. Add new sub leaf which not existed before, impact CPUID includes: 1. CPUID_INTEL_RDT_ALLOCATION 0x10 CPUID_INTEL_RDT_ALLOCATION_MEMORY_BANDWIDTH_SUB_LEAF 0x03 5. Add new CPUIDs which not exist before, new CPUIDs include: 1. CPUID_DETERMINISTIC_ADDRESS_TRANSLATION_PARAMETERS 0x18 2. CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION 0x1F Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CommonFeature: Always set FEATURE_CONTROL.Lockedk2-stable201811Ruiyu Ni2018-11-141-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1305 The patch reverts commit 1ed6498c4a0210204bf4b95cc0c0cd6623ad6a0b * UefiCpuPkg/CommonFeature: Skip locking when the feature is disabled FEATURE_CONTROL.Lock bit is controlled by feature CPU_FEATURE_LOCK_FEATURE_CONTROL_REGISTER. The commit 1ed649 fixes a bug that when the feature is disabled, the Lock bit is cleared. But it's a security hole if the bit is cleared when booting OS. We can argue that platform needs to make sure the value of PcdCpuFeaturesUserConfiguration should be set properly to make sure feature CPU_FEATURE_LOCK_FEATURE_CONTROL_REGISTER is enabled. But it's better to guarantee this in the generic core code. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Michael D Kinney <michael.d.kinney@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Separate semaphore container.Eric Dong2018-11-111-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In current implementation, core and package level sync uses same semaphores. Sharing the semaphore may cause wrong execution order. For example: 1. Feature A has CPU_FEATURE_CORE_BEFORE dependency with Feature B. 2. Feature C has CPU_FEATURE_PACKAGE_AFTER dependency with Feature B. The expected feature initialization order is A B C: A ---- (Core Depends) ----> B ---- (Package Depends) ----> C For a CPU has 1 package, 2 cores and 4 threads. The feature initialization order may like below: Thread#1 Thread#2 Thread#3 Thread#4 [A.Init] [A.Init] [A.Init] Release(S1, S2) Release(S1, S2) Release(S3, S4) Wait(S1) * 2 Wait(S2) * 2 <------------------------------- Core sync [B.Init] [B.Init] Release (S1,S2,S3,S4) Wait (S1) * 4 <----------------------------------------------------- Package sync Wait(S4 * 2) <- Core sync [B.Init] In above case, for thread#4, when it syncs in core level, Wait(S4) * 2 isn't blocked and [B.Init] runs. But [A.Init] hasn't run in thread#3. It's wrong! Thread#4 should execute [B.Init] after thread#3 executes [A.Init] because B core level depends on A. The reason of the wrong execution order is that S4 is released in thread#1 by calling Release (S1, S2, S3, S4) and in thread #4 by calling Release (S3, S4). To fix this issue, core level sync and package level sync should use separate semaphores. In above example, the S4 released in Release (S1, S2, S3, S4) should not be the same semaphore as that in Release (S3, S4). Related BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1311 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Separate semaphore container.Eric Dong2018-11-112-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In current implementation, core and package level sync uses same semaphores. Sharing the semaphore may cause wrong execution order. For example: 1. Feature A has CPU_FEATURE_CORE_BEFORE dependency with Feature B. 2. Feature C has CPU_FEATURE_PACKAGE_AFTER dependency with Feature B. The expected feature initialization order is A B C: A ---- (Core Depends) ----> B ---- (Package Depends) ----> C For a CPU has 1 package, 2 cores and 4 threads. The feature initialization order may like below: Thread#1 Thread#2 Thread#3 Thread#4 [A.Init] [A.Init] [A.Init] Release(S1, S2) Release(S1, S2) Release(S3, S4) Wait(S1) * 2 Wait(S2) * 2 <------------------------------- Core sync [B.Init] [B.Init] Release (S1,S2,S3,S4) Wait (S1) * 4 <----------------------------------------------------- Package sync Wait(S4 * 2) <- Core sync [B.Init] In above case, for thread#4, when it syncs in core level, Wait(S4) * 2 isn't blocked and [B.Init] runs. But [A.Init] hasn't run in thread#3. It's wrong! Thread#4 should execute [B.Init] after thread#3 executes [A.Init] because B core level depends on A. The reason of the wrong execution order is that S4 is released in thread#1 by calling Release (S1, S2, S3, S4) and in thread #4 by calling Release (S3, S4). To fix this issue, core level sync and package level sync should use separate semaphores. In above example, the S4 released in Release (S1, S2, S3, S4) should not be the same semaphore as that in Release (S3, S4). Related BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1311 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Adjust Order.Eric Dong2018-11-113-20/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V2 changes: V1 change has regression which caused by change feature order. V2 changes logic to detect dependence not only for the neighborhood features. It need to check all features in the list. V1 Changes: In current code logic, only adjust feature position if current CPU feature position not follow the request order. Just like Feature A need to be executed before feature B, but current feature A registers after feature B. So code will adjust the position for feature A, move it to just before feature B. If the position already met the requirement, code will not adjust the position. This logic has issue when met all below cases: 1. feature A has core or package level dependence with feature B. 2. feature A is register before feature B. 3. Also exist other features exist between feature A and B. Root cause is driver ignores the dependence for this case, so threads may execute not follow the dependence order. Fix this issue by change code logic to adjust feature position for CPU features which has dependence relationship. Related BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1311 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
* UefiCpuPkg/SmmCpu: Block access-out only when static paging is usedJiewen Yao2018-11-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | When static paging is disabled, page table for below 4GB is created and page table for above 4GB is created dynamically in page fault handler. Today's implementation only allow SMM access-out to below types of memory address no matter static paging is enabled or not: 1. Reserved, run time and ACPI NVS type 2. MMIO But certain platform feature like RAS may need to access other types of memory from SMM. Today's code blocks these platforms. This patch simplifies the policy to only block when static paging is used so that the static paging can be disabled in these platforms to meet their SMM access-out need. Setting PcdCpuSmmStaticPageTable to FALSE can disable the static paging. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CommonFeature: Skip locking when the feature is disabledRuiyu Ni2018-11-071-1/+10
| | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1305 Today's code unconditionally sets the IA32_FEATURE_CONTROL.Lock to 1 no matter the feature is enabled or not. The patch fixes this issue by only setting the Lock bit to 1 when the feature is enabled. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MpInitLib: Rollback old change 2a5997f8.Dong, Eric2018-11-052-4/+7
| | | | | | | | | | | | | | | In some special cases, after BSP sends Init-sipi-sipi signal AP needs more time to start the Ap procedure. In this case BSP may think AP has finished its task but in fact AP hasn't began yet. Rollback former change to keep the status which only be used when AP really finished task. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Fix build failure.Eric Dong2018-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | Build UefiCpuPkg with below configuration: Architecture(s) = IA32 Build target = NOOPT Toolchain = VS2015x86 Below error info shows up: DxeRegisterCpuFeaturesLib.lib(CpuFeaturesInitialize.obj) : error LNK2001: unresolved external symbol __allmul Valid mDependTypeStr type only have 5 items, use UINT32 type cast to fix this error. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Fix ASSERT for success.Marvin H?user2018-10-301-2/+1
| | | | | | | | | | | | | | | | | | | | | Index is initialized to MAX_UINT16 as default failure value, which is what the ASSERT is supposed to test for. The ASSERT condition however can never return FALSE for INT16 != int, as due to Integer Promotion[1], Index is converted to int, which can never result in -1. Furthermore, Index is used as a for loop index variable inbetween its initialization and the ASSERT, so the value is unconditionally overwritten too. Fix the ASSERT check to compare Index to its upper boundary, which it will be equal to if the loop was not broken out of on success. [1] ISO/IEC 9899:2011, 6.5.9.4 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Fix ASSERT for success.Marvin H?user2018-10-301-2/+1
| | | | | | | | | | | | | | | | | | | | | Index is initialized to MAX_UINT16 as default failure value, which is what the ASSERT is supposed to test for. The ASSERT condition however can never return FALSE for INT16 != int, as due to Integer Promotion[1], Index is converted to int, which can never result in -1. Furthermore, Index is used as a for loop index variable inbetween its initialization and the ASSERT, so the value is unconditionally overwritten too. Fix the ASSERT check to compare Index to its upper boundary, which it will be equal to if the loop was not broken out of on success. [1] ISO/IEC 9899:2011, 6.5.9.4 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Fix GCC build failure.Dong, Eric2018-10-272-2/+2
| | | | | | | Cc: Liming Gao <liming.gao@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Support combo CPU feature style.Eric Dong2018-10-263-67/+45
| | | | | | | | | | | | Current code assume only one dependence (before or after) for one feature. Enhance code logic to support feature has two dependence (before and after) type. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Fix build failure for VS2012 and GCC49.Eric Dong2018-10-261-0/+1
| | | | | | | | | | | | Code initialized in function can't be correctly detected by build tool. Add code to clearly initialize the local variable before use it. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Dandan Bi <dandan.bi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Clean up useless code.Eric Dong2018-10-262-25/+1
| | | | | | | | | | | Remove useless code after change 93324390. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Dandan Bi <dandan.bi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Remove white space at line end.Eric Dong2018-10-261-2/+2
| | | | | | | | | | | Remove extra white space at the end of line. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Dandan Bi <dandan.bi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Fix ECC issues.Eric Dong2018-10-262-12/+14
| | | | | | | | | | | | | | Changes include: 1. Remove extra white space at the end of line. 2. Add comments for the new add function parameter. 3. Update IN OUT tag for function parameter. Cc: Dandan Bi <dandan.bi@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/CpuCommonFeaturesLib: Remove white space at line end.Eric Dong2018-10-261-1/+1
| | | | | | | | | | | Remove extra white space at the end of line. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Dandan Bi <dandan.bi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Fix build failure for VS2012 and GCC49.Eric Dong2018-10-261-0/+1
| | | | | | | | | | | | Code initialized in function can't be correctly detected by build tool. Add code to clearly initialize the local variable before use it. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Dandan Bi <dandan.bi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/CpuDxe: prevent recursive calling of InitializePageTablePoolJian J Wang2018-10-261-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The freed-memory guard feature will cause a recursive calling of InitializePageTablePool(). This is due to a fact that AllocateAlignedPages() is used to allocate page table pool memory. This function will most likely call gBS->FreePages to free unaligned pages and then cause another round of page attributes change, like below (freed pages will be always marked not-present if freed-memory guard is enabled) FreePages() <===============| => CpuSetMemoryAttributes() | => <if out of page table> | => InitializePageTablePool() | => AllocateAlignedPages() | => FreePages() ================| The solution is add a global variable as a lock in page table pool allocation function and fail any other requests if it has not been done. Since this issue will only happen if free-memory guard is enabled, it won't affect CpuSetMemoryAttributes() in default build of a BIOS. If free-memory guard is enabled, it only affect the pages (failed to mark them as not-present) freed in AllocateAlignedPages(). Since those freed pages haven't been used yet (their addresses not yet exposed to code outside AllocateAlignedPages), it won't compromise the freed-memory guard feature. This change will just fail the CpuSetMemoryAttributes() called from FreePages() but it won't fail the FreePages(). So the error status won't be propagated upper layer of code. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/CpuDxe: consider freed-memory guard in non-stop modeJian J Wang2018-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Non-stop mode was introduced / explained in commit 8f2613628acf ("MdeModulePkg/MdeModulePkg.dec: add new settings for PCDs", 2018-08-30). The macro HEAP_GUARD_NONSTOP_MODE was added to CpuDxe in commit dcc026217fdc ("UefiCpuPkg/CpuDxe: implement non-stop mode for uefi", 2018-08-30). Another instance of the macro HEAP_GUARD_NONSTOP_MODE was added to PiSmmCpuDxeSmm -- with BIT1|BIT0 replaced with BIT3|BIT2 -- in commit 09afd9a42a7f ("UefiCpuPkg/PiSmmCpuDxeSmm: implement non-stop mode for SMM", 2018-08-30) Since the freed-memory guard is for UEFI-only. This patch only updates HEAP_GUARD_NONSTOP_MODE in "UefiCpuPkg/CpuDxe/CpuDxe.h" (add BIT4). Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/CpuCommonFeaturesLib: Register MSR base on scope Info.Eric Dong2018-10-2212-0/+190
| | | | | | | | | | | | | Because MSR has scope attribute, driver has no needs to set MSR for all APs if MSR scope is core or package type. This patch updates code to base on the MSR scope value to add MSR to the register table. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/CpuS3DataDxe: Keep old data if value already existed.Eric Dong2018-10-221-0/+2
| | | | | | | | | | | | AcpiCpuData add new fields, keep these fields if old data already existed. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Add logic to support semaphore type.Eric Dong2018-10-223-143/+276
| | | | | | | | | | | | | | | | | | | | | | | | | | V4 changes: 1. Serial console log for different threads when program register table. 2. Check the AcpiCpuData before use it to avoid potential ASSERT. V3 changes: 1. Use global variable instead of internal function to return string for register type and dependence type. 2. Add comments for some complicated logic. V1 changes: Because this driver needs to set MSRs saved in normal boot phase, sync semaphore logic from RegisterCpuFeaturesLib code which used for normal boot phase. Detail see below change for RegisterCpuFeaturesLib: UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type.Eric Dong2018-10-226-133/+939
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V4 changes include: 1. Serial debug message for different threads when program the register table. V3 changes include: 1. Use global variable instead of internal function to return string for register type and dependence type. 2. Add comments for some complicated logic. V2 changes include: 1. Add more description for the code part which need easy to understand. 2. Refine some code base on feedback for V1 changes. V1 changes include: In a system which has multiple cores, current set register value task costs huge times. After investigation, current set MSR task costs most of the times. Current logic uses SpinLock to let set MSR task as an single thread task for all cores. Because MSR has scope attribute which may cause GP fault if multiple APs set MSR at the same time, current logic use an easiest solution (use SpinLock) to avoid this issue, but it will cost huge times. In order to fix this performance issue, new solution will set MSRs base on their scope attribute. After this, the SpinLock will not needed. Without SpinLock, new issue raised which is caused by MSR dependence. For example, MSR A depends on MSR B which means MSR A must been set after MSR B has been set. Also MSR B is package scope level and MSR A is thread scope level. If system has multiple threads, Thread 1 needs to set the thread level MSRs and thread 2 needs to set thread and package level MSRs. Set MSRs task for thread 1 and thread 2 like below: Thread 1 Thread 2 MSR B N Y MSR A Y Y If driver don't control execute MSR order, for thread 1, it will execute MSR A first, but at this time, MSR B not been executed yet by thread 2. system may trig exception at this time. In order to fix the above issue, driver introduces semaphore logic to control the MSR execute sequence. For the above case, a semaphore will be add between MSR A and B for all threads. Semaphore has scope info for it. The possible scope value is core or package. For each thread, when it meets a semaphore during it set registers, it will 1) release semaphore (+1) for each threads in this core or package(based on the scope info for this semaphore) 2) acquire semaphore (-1) for all the threads in this core or package(based on the scope info for this semaphore). With these two steps, driver can control MSR sequence. Sample code logic like below: // // First increase semaphore count by 1 for processors in this package. // for (ProcessorIndex = 0; ProcessorIndex < PackageThreadsCount ; ProcessorIndex ++) { LibReleaseSemaphore ((UINT32 *) &SemaphorePtr[PackageOffset + ProcessorIndex]); } // // Second, check whether the count has reach the check number. // for (ProcessorIndex = 0; ProcessorIndex < ValidApCount; ProcessorIndex ++) { LibWaitForSemaphore (&SemaphorePtr[ApOffset]); } Platform Requirement: 1. This change requires register MSR setting base on MSR scope info. If still register MSR for all threads, exception may raised. Known limitation: 1. Current CpuFeatures driver supports DXE instance and PEI instance. But semaphore logic requires Aps execute in async mode which is not supported by PEI driver. So CpuFeature PEI instance not works after this change. We plan to support async mode for PEI in phase 2 for this task. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/RegisterCpuFeaturesLib.h: Add new dependence types.Eric Dong2018-10-221-4/+17
| | | | | | | | | | | | | | | | | | V4 changes: 1. Update comments. v3 changes: 1. Move CPU_FEATURE_DEPENDENCE_TYPE definition to AcpiCpuData.h. 2. Add comments for CPU_FEATURE_BEFORE/CPU_FEATURE_AFTER. v1 changes: Add new core/package dependence types which consumed by different MSRs. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.Eric Dong2018-10-221-1/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v3 changes: 1. Move CPU_FEATURE_DEPENDENCE_TYPE definition here from RegisterCpuFeaturesLib.h file. 2. Add Invalid type for REGISTER_TYPE which will be used in code. v2 changes: 1. Add more description about why we do this change. 2. Change structure field type from pointer to EFI_PHYSICAL_ADDRESS because it will be share between PEI and DXE. v1 Changes: In order to support semaphore related logic, add new definition for it. In a system which has multiple cores, current set register value task costs huge times. After investigation, current set MSR task costs most of the times. Current logic uses SpinLock to let set MSR task as an single thread task for all cores. Because MSR has scope attribute which may cause GP fault if multiple APs set MSR at the same time, current logic use an easiest solution (use SpinLock) to avoid this issue, but it will cost huge times. In order to fix this performance issue, new solution will set MSRs base on their scope attribute. After this, the SpinLock will not needed. Without SpinLock, new issue raised which is caused by MSR dependence. For example, MSR A depends on MSR B which means MSR A must been set after MSR B has been set. Also MSR B is package scope level and MSR A is thread scope level. If system has multiple threads, Thread 1 needs to set the thread level MSRs and thread 2 needs to set thread and package level MSRs. Set MSRs task for thread 1 and thread 2 like below: Thread 1 Thread 2 MSR B N Y MSR A Y Y If driver don't control execute MSR order, for thread 1, it will execute MSR A first, but at this time, MSR B not been executed yet by thread 2. system may trig exception at this time. In order to fix the above issue, driver introduces semaphore logic to control the MSR execute sequence. For the above case, a semaphore will be add between MSR A and B for all threads. Semaphore has scope info for it. The possible scope value is core or package. For each thread, when it meets a semaphore during it set registers, it will 1) release semaphore (+1) for each threads in this core or package(based on the scope info for this semaphore) 2) acquire semaphore (-1) for all the threads in this core or package(based on the scope info for this semaphore). With these two steps, driver can control MSR sequence. Sample code logic like below: // // First increase semaphore count by 1 for processors in this package. // for (ProcessorIndex = 0; ProcessorIndex < PackageThreadsCount ; ProcessorIndex ++) { LibReleaseSemaphore ((UINT32 *) &SemaphorePtr[PackageOffset + ProcessorIndex]); } // // Second, check whether the count has reach the check number. // for (ProcessorIndex = 0; ProcessorIndex < ValidApCount; ProcessorIndex ++) { LibWaitForSemaphore (&SemaphorePtr[ApOffset]); } Platform Requirement: 1. This change requires register MSR setting base on MSR scope info. If still register MSR for all threads, exception may raised. Known limitation: 1. Current CpuFeatures driver supports DXE instance and PEI instance. But semaphore logic requires Aps execute in async mode which is not supported by PEI driver. So CpuFeature PEI instance not works after this change. We plan to support async mode for PEI in phase 2 for this task. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuExceptionHandlerLib: always clear descriptor data in advanceJian J Wang2018-10-182-0/+6
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1237 Sometimes the memory will be contaminated by random data left in last boot (warm reset). The code should not assume the allocated memory is always filled with zero. This patch add code to clear data structure used for stack switch to prevent such problem from happening. Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* UefiCpuPkg/S3Resume2Pei: disable paging before creating new page table.Eric Dong2018-10-152-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V5: 1. Add ASSERT to indicate this assumption that environment is 32 bit mode. 2. Add description in INF about this driver's expected result in different environment. V4: Only disable paging when it is enabled. V3 changes: No need to change inf file. V2 changes: Only disable paging in 32 bit mode, no matter it is enable or not. V1 changes: PEI Stack Guard needs to enable paging. This might cause #GP if code trying to write CR3 register with PML4 page table while the processor is enabled with PAE paging. Simply disabling paging before updating CR3 can solve this conflict. It's an regression caused by change: 0a0d5296e448fc350de1594c49b9c0deff7fad60 BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1232 Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: [CVE-2017-5753] Fix bounds check bypassHao Wu2018-09-301-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1194 Speculative execution is used by processor to avoid having to wait for data to arrive from memory, or for previous operations to finish, the processor may speculate as to what will be executed. If the speculation is incorrect, the speculatively executed instructions might leave hints such as which memory locations have been brought into cache. Malicious actors can use the bounds check bypass method (code gadgets with controlled external inputs) to infer data values that have been used in speculative operations to reveal secrets which should not otherwise be accessed. It is possible for SMI handler(s) to call EFI_SMM_CPU_PROTOCOL service ReadSaveState() and use the content in the 'CommBuffer' (controlled external inputs) as the 'CpuIndex'. So this commit will insert AsmLfence API to mitigate the bounds check bypass issue within SmmReadSaveState(). For SmmReadSaveState(): The 'CpuIndex' will be passed into function ReadSaveStateRegister(). And then in to ReadSaveStateRegisterByIndex(). With the call: ReadSaveStateRegisterByIndex ( CpuIndex, SMM_SAVE_STATE_REGISTER_IOMISC_INDEX, sizeof(IoMisc.Uint32), &IoMisc.Uint32 ); The 'IoMisc' can be a cross boundary access during speculative execution. Later, 'IoMisc' is used as the index to access buffers 'mSmmCpuIoWidth' and 'mSmmCpuIoType'. One can observe which part of the content within those buffers was brought into cache to possibly reveal the value of 'IoMisc'. Hence, this commit adds a AsmLfence() after the check of 'CpuIndex' within function SmmReadSaveState() to prevent the speculative execution. A more detailed explanation of the purpose of commit is under the 'Bounds check bypass mitigation' section of the below link: https://software.intel.com/security-software-guidance/insights/host-firmware-speculative-execution-side-channel-mitigation And the document at: https://software.intel.com/security-software-guidance/api-app/sites/default/files/337879-analyzing-potential-bounds-Check-bypass-vulnerabilities.pdf Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h: Change to DOS format file.Eric Dong2018-09-301-272/+272
| | | | | | | | | | | | | Follow EDKII coding style, change file format to dos style. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1213 Cc: Dandan Bi <dandan.bi@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuCommonFeaturesLib: Remove an unused PCDshenglei2018-09-291-1/+0
| | | | | | | | | | | The PCD below is unused, so it has been removed from inf. gUefiCpuPkgTokenSpaceGuid.PcdCpuFeaturesSupport Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: shenglei <shenglei.zhang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg PiSmmCpuDxeSmm: Use new EfiLocateFirstAcpiTable()Star Zeng2018-09-273-85/+6
| | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=967 Request to add a library function for GetAcpiTable() in order to get ACPI table using signature as input. After evaluation, we found there are many duplicated code to find ACPI table by signature in different modules. This patch updates PiSmmCpuDxeSmm to use new EfiLocateFirstAcpiTable() and remove the duplicated code. Cc: Younas khan <pmdyounaskhan786@gmail.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/Include/Register/Msr/XeonPhiMsr.h: Change structure definition.Eric Dong2018-09-261-9/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V3 changes include: 1. Keep the ReservedX not change if bit info not changed for this field. V2 changes include: 1. Use X in ReservedX fields from totally new value if MSR structure definition changed. For example, if in current structure, the max reserved variable is Reserved2, in new definition, reserved variable is begin with Reserved3. V1 Changes: Changes includes: 1. Update MSR structure definition, change some reserved fields to useful fields: 1. MSR_XEON_PHI_PKG_CST_CONFIG_CONTROL_REGISTER 2. MSR_XEON_PHI_SMM_MCA_CAP_REGISTER 2. For MSR_XEON_PHI_PMG_IO_CAPTURE_BASE_REGISTER structure, it expand the field range. Old definition like below: typedef union { /// /// Individual bit fields /// struct { /// /// [Bits 15:0] LVL_2 Base Address (R/W). /// UINT32 Lvl2Base:16; /// /// [Bits 18:16] C-state Range (R/W) Specifies the encoding value of the /// maximum C-State code name to be included when IO read to MWAIT /// redirection is enabled by MSR_PKG_CST_CONFIG_CONTROL[bit10]: 100b - C4 /// is the max C-State to include 110b - C6 is the max C-State to include. /// UINT32 CStateRange:3; UINT32 Reserved1:13; UINT32 Reserved2:32; } Bits; /// /// All bit fields as a 32-bit value /// UINT32 Uint32; /// /// All bit fields as a 64-bit value /// UINT64 Uint64; } MSR_XEON_PHI_PMG_IO_CAPTURE_BASE_REGISTER; This patch make below changes for this data structure, it expand "CStateRange" field width. old one: UINT32 CStateRange:3; UINT32 Reserved1:13; new one: UINT32 CStateRange:7; UINT32 Reserved1:9; Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/Include/Register/ArchitecturalMsr.h: Change structure definition.Eric Dong2018-09-261-2/+12
| | | | | | | | | | | | | | | | | | | | | V3 changes include: 1. Keep ReservedX not change if bit info not changed for this field. V2 changes include: 1. Use X in ReservedX fields from totally new value if MSR structure definition changed. For example, if in current structure, the max reserved variable is Reserved2, in new definition, reserved variable is begin with Reserved3. V1 Changes includes: 1. Change fields which is reserved in old version: MSR_IA32_RTIT_CTL_REGISTER Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/Include/Register/Msr/GoldmontMsr.h: Add new MSR name and keep old ↵Eric Dong2018-09-261-10/+24
| | | | | | | | | | | | | | | | | | | | one. Changes includes: 1. Change MSR name: 1. MSR_GOLDMONT_SGXOWNER0 => MSR_GOLDMONT_SGXOWNEREPOCH0 2. MSR_GOLDMONT_SGXOWNER1 => MSR_GOLDMONT_SGXOWNEREPOCH1 2. Keep old MSR definition (MSR_GOLDMONT_SGXOWNER0/1) for compatibility. 1. Define old MSR like below style: #define MSR_GOLDMONT_SGXOWNER0 MSR_GOLDMONT_SGXOWNEREPOCH0 Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/Include/Register/Msr/SkylakeMsr.h: Add new MSR name and keep old one.Eric Dong2018-09-261-13/+27
| | | | | | | | | | | | | | | | | | Changes includes: 1. Change MSR name: 1. MSR_SKYLAKE_SGXOWNER0 => MSR_SKYLAKE_SGXOWNEREPOCH0 2. MSR_SKYLAKE_SGXOWNER1 => MSR_SKYLAKE_SGXOWNEREPOCH1 2. Keep old MSR definition(MSR_SKYLAKE_SGXOWNER0/1) for compatibility 1. Use below coding style to define old MSR #define MSR_SKYLAKE_SGXOWNER0 MSR_SKYLAKE_SGXOWNEREPOCH0 Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>