2015-10-19 21:12:04 +02:00
|
|
|
/** @file
|
|
|
|
|
Definitions for CPU S3 data.
|
|
|
|
|
|
2021-09-16 11:27:11 +02:00
|
|
|
Copyright (c) 2013 - 2021, Intel Corporation. All rights reserved.<BR>
|
2019-04-04 01:07:22 +02:00
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
2015-10-19 21:12:04 +02:00
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
|
|
#ifndef _ACPI_CPU_DATA_H_
|
|
|
|
|
#define _ACPI_CPU_DATA_H_
|
|
|
|
|
|
2021-09-16 11:27:11 +02:00
|
|
|
//
|
|
|
|
|
// This macro definition is used to fix incompatibility issue caused by
|
|
|
|
|
// ACPI_CPU_DATA structure update. It will be removed after all the platform
|
|
|
|
|
// code uses new ACPI_CPU_DATA structure.
|
|
|
|
|
//
|
|
|
|
|
#define ACPI_CPU_DATA_STRUCTURE_UPDATE
|
|
|
|
|
|
2015-10-19 21:12:04 +02:00
|
|
|
//
|
|
|
|
|
// Register types in register table
|
|
|
|
|
//
|
2015-11-25 18:00:51 +01:00
|
|
|
typedef enum {
|
2015-10-19 21:12:04 +02:00
|
|
|
Msr,
|
|
|
|
|
ControlRegister,
|
|
|
|
|
MemoryMapped,
|
UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.
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>
2018-10-15 03:19:18 +02:00
|
|
|
CacheControl,
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// Semaphore type used to control the execute sequence of the Msr.
|
|
|
|
|
// It will be insert between two Msr which has execute dependence.
|
|
|
|
|
//
|
|
|
|
|
Semaphore,
|
|
|
|
|
InvalidReg
|
2015-10-19 21:12:04 +02:00
|
|
|
} REGISTER_TYPE;
|
|
|
|
|
|
UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.
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>
2018-10-15 03:19:18 +02:00
|
|
|
//
|
|
|
|
|
// Describe the dependency type for different features.
|
|
|
|
|
// The value set to CPU_REGISTER_TABLE_ENTRY.Value when the REGISTER_TYPE is Semaphore.
|
|
|
|
|
//
|
|
|
|
|
typedef enum {
|
|
|
|
|
NoneDepType,
|
|
|
|
|
ThreadDepType,
|
|
|
|
|
CoreDepType,
|
|
|
|
|
PackageDepType,
|
|
|
|
|
InvalidDepType
|
|
|
|
|
} CPU_FEATURE_DEPENDENCE_TYPE;
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// CPU information.
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
|
|
|
|
//
|
|
|
|
|
// Record the package count in this CPU.
|
|
|
|
|
//
|
|
|
|
|
UINT32 PackageCount;
|
|
|
|
|
//
|
|
|
|
|
// Record the max core count in this CPU.
|
|
|
|
|
// Different packages may have different core count, this value
|
|
|
|
|
// save the max core count in all the packages.
|
|
|
|
|
//
|
|
|
|
|
UINT32 MaxCoreCount;
|
|
|
|
|
//
|
|
|
|
|
// Record the max thread count in this CPU.
|
|
|
|
|
// Different cores may have different thread count, this value
|
|
|
|
|
// save the max thread count in all the cores.
|
|
|
|
|
//
|
|
|
|
|
UINT32 MaxThreadCount;
|
|
|
|
|
//
|
|
|
|
|
// This field points to an array.
|
2020-12-02 02:51:31 +01:00
|
|
|
// This array saves thread count (type UINT32) of each package.
|
UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.
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>
2018-10-15 03:19:18 +02:00
|
|
|
// The array has PackageCount elements.
|
|
|
|
|
//
|
|
|
|
|
// If the platform does not support MSR setting at S3 resume, and
|
|
|
|
|
// therefore it doesn't need the dependency semaphores, it should set
|
|
|
|
|
// this field to 0.
|
|
|
|
|
//
|
2020-12-02 02:51:31 +01:00
|
|
|
EFI_PHYSICAL_ADDRESS ThreadCountPerPackage;
|
|
|
|
|
//
|
|
|
|
|
// This field points to an array.
|
|
|
|
|
// This array saves thread count (type UINT8) of each core.
|
|
|
|
|
// The array has PackageCount * MaxCoreCount elements.
|
|
|
|
|
//
|
|
|
|
|
// If the platform does not support MSR setting at S3 resume, and
|
|
|
|
|
// therefore it doesn't need the dependency semaphores, it should set
|
|
|
|
|
// this field to 0.
|
|
|
|
|
//
|
|
|
|
|
EFI_PHYSICAL_ADDRESS ThreadCountPerCore;
|
UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.
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>
2018-10-15 03:19:18 +02:00
|
|
|
} CPU_STATUS_INFORMATION;
|
|
|
|
|
|
2015-10-19 21:12:04 +02:00
|
|
|
//
|
|
|
|
|
// Element of register table entry
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
2017-03-23 06:19:49 +01:00
|
|
|
REGISTER_TYPE RegisterType; // offset 0 - 3
|
|
|
|
|
UINT32 Index; // offset 4 - 7
|
|
|
|
|
UINT8 ValidBitStart; // offset 8
|
|
|
|
|
UINT8 ValidBitLength; // offset 9
|
2019-08-16 05:57:25 +02:00
|
|
|
BOOLEAN TestThenWrite; // offset 10
|
|
|
|
|
UINT8 Reserved1; // offset 11
|
2017-03-23 06:19:49 +01:00
|
|
|
UINT32 HighIndex; // offset 12-15, only valid for MemoryMapped
|
|
|
|
|
UINT64 Value; // offset 16-23
|
2015-10-19 21:12:04 +02:00
|
|
|
} CPU_REGISTER_TABLE_ENTRY;
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// Register table definition, including current table length,
|
|
|
|
|
// allocated size of this table, and pointer to the list of table entries.
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
|
|
|
|
// The number of valid entries in the RegisterTableEntry buffer
|
|
|
|
|
//
|
|
|
|
|
UINT32 TableLength;
|
|
|
|
|
UINT32 NumberBeforeReset;
|
|
|
|
|
//
|
|
|
|
|
// The size, in bytes, of the RegisterTableEntry buffer
|
|
|
|
|
//
|
|
|
|
|
UINT32 AllocatedSize;
|
|
|
|
|
//
|
|
|
|
|
// The initial APIC ID of the CPU this register table applies to
|
|
|
|
|
//
|
|
|
|
|
UINT32 InitialApicId;
|
|
|
|
|
//
|
2018-08-10 04:28:50 +02:00
|
|
|
// Physical address of CPU_REGISTER_TABLE_ENTRY structures.
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
2017-03-07 07:32:28 +01:00
|
|
|
EFI_PHYSICAL_ADDRESS RegisterTableEntry;
|
2015-10-19 21:12:04 +02:00
|
|
|
} CPU_REGISTER_TABLE;
|
|
|
|
|
|
2021-09-16 11:27:11 +02:00
|
|
|
//
|
|
|
|
|
// Data structure that is used for CPU feature initialization during ACPI S3
|
|
|
|
|
// resume.
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
|
|
|
|
//
|
|
|
|
|
// Physical address of an array of CPU_REGISTER_TABLE structures, with
|
|
|
|
|
// NumberOfCpus entries. If a register table is not required, then the
|
|
|
|
|
// TableLength and AllocatedSize fields of CPU_REGISTER_TABLE are set to 0.
|
|
|
|
|
// If TableLength is > 0, then elements of RegisterTableEntry are used to
|
|
|
|
|
// initialize the CPU that matches InitialApicId, during an ACPI S3 resume,
|
|
|
|
|
// before SMBASE relocation is performed.
|
|
|
|
|
// If a register table is not required for any one of the CPUs, then
|
|
|
|
|
// PreSmmInitRegisterTable may be set to 0.
|
|
|
|
|
//
|
|
|
|
|
EFI_PHYSICAL_ADDRESS PreSmmInitRegisterTable;
|
|
|
|
|
//
|
|
|
|
|
// Physical address of an array of CPU_REGISTER_TABLE structures, with
|
|
|
|
|
// NumberOfCpus entries. If a register table is not required, then the
|
|
|
|
|
// TableLength and AllocatedSize fields of CPU_REGISTER_TABLE are set to 0.
|
|
|
|
|
// If TableLength is > 0, then elements of RegisterTableEntry are used to
|
|
|
|
|
// initialize the CPU that matches InitialApicId, during an ACPI S3 resume,
|
|
|
|
|
// after SMBASE relocation is performed.
|
|
|
|
|
// If a register table is not required for any one of the CPUs, then
|
|
|
|
|
// RegisterTable may be set to 0.
|
|
|
|
|
//
|
|
|
|
|
EFI_PHYSICAL_ADDRESS RegisterTable;
|
|
|
|
|
//
|
|
|
|
|
// CPU information which is required when set the register table.
|
|
|
|
|
//
|
|
|
|
|
CPU_STATUS_INFORMATION CpuStatus;
|
|
|
|
|
//
|
|
|
|
|
// Location info for each AP.
|
|
|
|
|
// It points to an array which saves all APs location info.
|
|
|
|
|
// The array count is the AP count in this CPU.
|
|
|
|
|
//
|
|
|
|
|
// If the platform does not support MSR setting at S3 resume, and
|
|
|
|
|
// therefore it doesn't need the dependency semaphores, it should set
|
|
|
|
|
// this field to 0.
|
|
|
|
|
//
|
|
|
|
|
EFI_PHYSICAL_ADDRESS ApLocation;
|
|
|
|
|
} CPU_FEATURE_INIT_DATA;
|
|
|
|
|
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
2018-08-10 04:28:50 +02:00
|
|
|
// Data structure that is required for ACPI S3 resume. The PCD
|
2015-11-25 18:00:51 +01:00
|
|
|
// PcdCpuS3DataAddress must be set to the physical address where this structure
|
|
|
|
|
// is allocated
|
|
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
typedef struct {
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
|
|
|
|
// Physical address of 4KB buffer allocated below 1MB from memory of type
|
|
|
|
|
// EfiReservedMemoryType. The buffer is not required to be initialized, but
|
|
|
|
|
// it is recommended that the buffer be zero-filled. This buffer is used to
|
|
|
|
|
// wake APs during an ACPI S3 resume.
|
|
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
EFI_PHYSICAL_ADDRESS StartupVector;
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
2018-08-10 04:28:50 +02:00
|
|
|
// Physical address of structure of type IA32_DESCRIPTOR. The
|
2015-11-25 18:00:51 +01:00
|
|
|
// IA32_DESCRIPTOR structure provides the base address and length of a GDT
|
2018-08-10 04:28:50 +02:00
|
|
|
// The GDT must be filled in with the GDT contents that are
|
2015-11-25 18:00:51 +01:00
|
|
|
// used during an ACPI S3 resume. This is typically the contents of the GDT
|
|
|
|
|
// used by the boot processor when the platform is booted.
|
|
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
EFI_PHYSICAL_ADDRESS GdtrProfile;
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
2018-08-10 04:28:50 +02:00
|
|
|
// Physical address of structure of type IA32_DESCRIPTOR. The
|
2015-11-25 18:00:51 +01:00
|
|
|
// IA32_DESCRIPTOR structure provides the base address and length of an IDT.
|
2018-08-10 04:28:50 +02:00
|
|
|
// The IDT must be filled in with the IDT contents that are
|
2015-11-25 18:00:51 +01:00
|
|
|
// used during an ACPI S3 resume. This is typically the contents of the IDT
|
|
|
|
|
// used by the boot processor when the platform is booted.
|
|
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
EFI_PHYSICAL_ADDRESS IdtrProfile;
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
|
|
|
|
// Physical address of a buffer that is used as stacks during ACPI S3 resume.
|
|
|
|
|
// The total size of this buffer, in bytes, is NumberOfCpus * StackSize. This
|
2018-08-10 04:28:50 +02:00
|
|
|
// structure must be allocated from memory of type EfiACPIMemoryNVS.
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
EFI_PHYSICAL_ADDRESS StackAddress;
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
|
|
|
|
// The size, in bytes, of the stack provided to each CPU during ACPI S3 resume.
|
|
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
UINT32 StackSize;
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
|
|
|
|
// The number of CPUs. If a platform does not support hot plug CPUs, then
|
|
|
|
|
// this is the number of CPUs detected when the platform is booted, regardless
|
|
|
|
|
// of being enabled or disabled. If a platform does support hot plug CPUs,
|
|
|
|
|
// then this is the maximum number of CPUs that the platform supports.
|
|
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
UINT32 NumberOfCpus;
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
|
|
|
|
// Physical address of structure of type MTRR_SETTINGS that contains a copy
|
|
|
|
|
// of the MTRR settings that are compatible with the MTRR settings used by
|
|
|
|
|
// the boot processor when the platform was booted. These MTRR settings are
|
2018-08-10 04:28:50 +02:00
|
|
|
// used during an ACPI S3 resume.
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
EFI_PHYSICAL_ADDRESS MtrrTable;
|
|
|
|
|
//
|
2015-11-25 18:00:51 +01:00
|
|
|
// Physical address of a buffer that contains the machine check handler that
|
2018-08-10 04:28:50 +02:00
|
|
|
// is used during an ACPI S3 Resume. In order for this machine check
|
2015-11-25 18:00:51 +01:00
|
|
|
// handler to be active on an AP during an ACPI S3 resume, the machine check
|
|
|
|
|
// vector in the IDT provided by IdtrProfile must be initialized to transfer
|
|
|
|
|
// control to this physical address.
|
|
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
EFI_PHYSICAL_ADDRESS ApMachineCheckHandlerBase;
|
2015-11-25 18:00:51 +01:00
|
|
|
//
|
|
|
|
|
// The size, in bytes, of the machine check handler that is used during an
|
|
|
|
|
// ACPI S3 Resume. If this field is 0, then a machine check handler is not
|
|
|
|
|
// provided.
|
|
|
|
|
//
|
2015-10-19 21:12:04 +02:00
|
|
|
UINT32 ApMachineCheckHandlerSize;
|
UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.
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>
2018-10-15 03:19:18 +02:00
|
|
|
//
|
2021-09-16 11:27:11 +02:00
|
|
|
// Data structure that is used for CPU feature initialization during ACPI S3
|
|
|
|
|
// resume.
|
UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information.
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>
2018-10-15 03:19:18 +02:00
|
|
|
//
|
2021-09-16 11:27:11 +02:00
|
|
|
CPU_FEATURE_INIT_DATA CpuFeatureInitData;
|
2015-10-19 21:12:04 +02:00
|
|
|
} ACPI_CPU_DATA;
|
|
|
|
|
|
|
|
|
|
#endif
|
