2017-04-05 10:33:16 +02:00
|
|
|
/** @file
|
|
|
|
CPU Register Table Library functions.
|
|
|
|
|
|
|
|
Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
|
2019-04-04 01:07:22 +02:00
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
2017-04-05 10:33:16 +02:00
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
#include <PiPei.h>
|
|
|
|
|
|
|
|
#include <Library/HobLib.h>
|
|
|
|
#include <Library/PeiServicesLib.h>
|
|
|
|
#include <Library/PeiServicesTablePointerLib.h>
|
|
|
|
#include <Ppi/MpServices.h>
|
|
|
|
#include "RegisterCpuFeatures.h"
|
|
|
|
|
|
|
|
#define REGISTER_CPU_FEATURES_GUID \
|
|
|
|
{ \
|
|
|
|
0xa694c467, 0x697a, 0x446b, { 0xb9, 0x29, 0x5b, 0x14, 0xa0, 0xcf, 0x39, 0xf } \
|
|
|
|
}
|
|
|
|
|
|
|
|
EFI_GUID mRegisterCpuFeaturesHobGuid = REGISTER_CPU_FEATURES_GUID;
|
|
|
|
|
|
|
|
/**
|
|
|
|
Worker function to get CPU_FEATURES_DATA pointer.
|
|
|
|
|
|
|
|
@return Pointer to CPU_FEATURES_DATA.
|
|
|
|
**/
|
|
|
|
CPU_FEATURES_DATA *
|
|
|
|
GetCpuFeaturesData (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
CPU_FEATURES_DATA *CpuInitData;
|
|
|
|
EFI_HOB_GUID_TYPE *GuidHob;
|
|
|
|
VOID *DataInHob;
|
|
|
|
UINT64 Data64;
|
|
|
|
|
|
|
|
CpuInitData = NULL;
|
|
|
|
GuidHob = GetFirstGuidHob (&mRegisterCpuFeaturesHobGuid);
|
|
|
|
if (GuidHob != NULL) {
|
|
|
|
DataInHob = GET_GUID_HOB_DATA (GuidHob);
|
|
|
|
CpuInitData = (CPU_FEATURES_DATA *) (*(UINTN *) DataInHob);
|
|
|
|
ASSERT (CpuInitData != NULL);
|
|
|
|
} else {
|
|
|
|
CpuInitData = AllocateZeroPool (sizeof (CPU_FEATURES_DATA));
|
|
|
|
ASSERT (CpuInitData != NULL);
|
|
|
|
//
|
|
|
|
// Build location of CPU MP DATA buffer in HOB
|
|
|
|
//
|
|
|
|
Data64 = (UINT64) (UINTN) CpuInitData;
|
|
|
|
BuildGuidDataHob (
|
|
|
|
&mRegisterCpuFeaturesHobGuid,
|
|
|
|
(VOID *) &Data64,
|
|
|
|
sizeof (UINT64)
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
return CpuInitData;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Worker function to get MP PPI service pointer.
|
|
|
|
|
2019-01-04 06:37:29 +01:00
|
|
|
@return MP_SERVICES variable.
|
2017-04-05 10:33:16 +02:00
|
|
|
**/
|
2019-01-04 06:37:29 +01:00
|
|
|
MP_SERVICES
|
|
|
|
GetMpService (
|
2017-04-05 10:33:16 +02:00
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
2019-01-04 06:37:29 +01:00
|
|
|
MP_SERVICES MpService;
|
2017-04-05 10:33:16 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Get MP Services Protocol
|
|
|
|
//
|
|
|
|
Status = PeiServicesLocatePpi (
|
|
|
|
&gEfiPeiMpServicesPpiGuid,
|
|
|
|
0,
|
|
|
|
NULL,
|
2019-01-04 06:37:29 +01:00
|
|
|
(VOID **)&MpService.Ppi
|
2017-04-05 10:33:16 +02:00
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
2019-01-04 06:37:29 +01:00
|
|
|
return MpService;
|
2017-04-05 10:33:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Worker function to return processor index.
|
|
|
|
|
2019-01-04 06:37:29 +01:00
|
|
|
@param CpuFeaturesData Cpu Feature Data structure.
|
|
|
|
|
2017-04-05 10:33:16 +02:00
|
|
|
@return The processor index.
|
|
|
|
**/
|
|
|
|
UINTN
|
|
|
|
GetProcessorIndex (
|
2019-01-04 06:37:29 +01:00
|
|
|
IN CPU_FEATURES_DATA *CpuFeaturesData
|
2017-04-05 10:33:16 +02:00
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_PEI_MP_SERVICES_PPI *CpuMpPpi;
|
|
|
|
UINTN ProcessorIndex;
|
|
|
|
|
2019-01-04 06:37:29 +01:00
|
|
|
CpuMpPpi = CpuFeaturesData->MpService.Ppi;
|
2017-04-05 10:33:16 +02:00
|
|
|
|
2019-01-04 06:37:29 +01:00
|
|
|
//
|
|
|
|
// For two reasons which use NULL for WhoAmI:
|
|
|
|
// 1. This function will be called by APs and AP should not use PeiServices Table
|
|
|
|
// 2. Check WhoAmI implementation, this parameter will not be used.
|
|
|
|
//
|
|
|
|
Status = CpuMpPpi->WhoAmI(NULL, CpuMpPpi, &ProcessorIndex);
|
2017-04-05 10:33:16 +02:00
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
return ProcessorIndex;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Worker function to MP-related information on the requested processor at the
|
|
|
|
instant this call is made.
|
|
|
|
|
|
|
|
@param[in] ProcessorNumber The handle number of processor.
|
|
|
|
@param[out] ProcessorInfoBuffer A pointer to the buffer where information for
|
|
|
|
the requested processor is deposited.
|
|
|
|
|
|
|
|
@return Status of MpServices->GetProcessorInfo().
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
GetProcessorInformation (
|
|
|
|
IN UINTN ProcessorNumber,
|
|
|
|
OUT EFI_PROCESSOR_INFORMATION *ProcessorInfoBuffer
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_PEI_MP_SERVICES_PPI *CpuMpPpi;
|
|
|
|
EFI_STATUS Status;
|
2019-01-04 06:37:29 +01:00
|
|
|
CPU_FEATURES_DATA *CpuFeaturesData;
|
|
|
|
|
|
|
|
CpuFeaturesData = GetCpuFeaturesData ();
|
|
|
|
CpuMpPpi = CpuFeaturesData->MpService.Ppi;
|
2017-04-05 10:33:16 +02:00
|
|
|
|
|
|
|
Status = CpuMpPpi->GetProcessorInfo (
|
|
|
|
GetPeiServicesTablePointer(),
|
|
|
|
CpuMpPpi,
|
|
|
|
ProcessorNumber,
|
|
|
|
ProcessorInfoBuffer
|
|
|
|
);
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Worker function to execute a caller provided function on all enabled APs.
|
|
|
|
|
|
|
|
@param[in] Procedure A pointer to the function to be run on
|
|
|
|
enabled APs of the system.
|
2018-10-25 03:51:00 +02:00
|
|
|
@param[in] MpEvent The Event used to sync the result.
|
|
|
|
|
2017-04-05 10:33:16 +02:00
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
StartupAPsWorker (
|
UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type.
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>
2018-10-17 03:31:03 +02:00
|
|
|
IN EFI_AP_PROCEDURE Procedure,
|
|
|
|
IN EFI_EVENT MpEvent
|
2017-04-05 10:33:16 +02:00
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_PEI_MP_SERVICES_PPI *CpuMpPpi;
|
UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type.
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>
2018-10-17 03:31:03 +02:00
|
|
|
CPU_FEATURES_DATA *CpuFeaturesData;
|
|
|
|
|
|
|
|
CpuFeaturesData = GetCpuFeaturesData ();
|
2019-01-04 06:37:29 +01:00
|
|
|
CpuMpPpi = CpuFeaturesData->MpService.Ppi;
|
2017-04-05 10:33:16 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Wakeup all APs for data collection.
|
|
|
|
//
|
|
|
|
Status = CpuMpPpi->StartupAllAPs (
|
|
|
|
GetPeiServicesTablePointer (),
|
|
|
|
CpuMpPpi,
|
|
|
|
Procedure,
|
|
|
|
FALSE,
|
|
|
|
0,
|
UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type.
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>
2018-10-17 03:31:03 +02:00
|
|
|
CpuFeaturesData
|
2017-04-05 10:33:16 +02:00
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Worker function to switch the requested AP to be the BSP from that point onward.
|
|
|
|
|
|
|
|
@param[in] ProcessorNumber The handle number of AP that is to become the new BSP.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
SwitchNewBsp (
|
|
|
|
IN UINTN ProcessorNumber
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_PEI_MP_SERVICES_PPI *CpuMpPpi;
|
2019-01-04 06:37:29 +01:00
|
|
|
CPU_FEATURES_DATA *CpuFeaturesData;
|
2017-04-05 10:33:16 +02:00
|
|
|
|
2019-01-04 06:37:29 +01:00
|
|
|
CpuFeaturesData = GetCpuFeaturesData ();
|
|
|
|
CpuMpPpi = CpuFeaturesData->MpService.Ppi;
|
2017-04-05 10:33:16 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Wakeup all APs for data collection.
|
|
|
|
//
|
|
|
|
Status = CpuMpPpi->SwitchBSP (
|
|
|
|
GetPeiServicesTablePointer (),
|
|
|
|
CpuMpPpi,
|
|
|
|
ProcessorNumber,
|
|
|
|
TRUE
|
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Worker function to retrieve the number of logical processor in the platform.
|
|
|
|
|
|
|
|
@param[out] NumberOfCpus Pointer to the total number of logical
|
|
|
|
processors in the system, including the BSP
|
|
|
|
and disabled APs.
|
|
|
|
@param[out] NumberOfEnabledProcessors Pointer to the number of enabled logical
|
|
|
|
processors that exist in system, including
|
|
|
|
the BSP.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
GetNumberOfProcessor (
|
|
|
|
OUT UINTN *NumberOfCpus,
|
|
|
|
OUT UINTN *NumberOfEnabledProcessors
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
EFI_PEI_MP_SERVICES_PPI *CpuMpPpi;
|
2019-01-04 06:37:29 +01:00
|
|
|
CPU_FEATURES_DATA *CpuFeaturesData;
|
2017-04-05 10:33:16 +02:00
|
|
|
|
2019-01-04 06:37:29 +01:00
|
|
|
CpuFeaturesData = GetCpuFeaturesData ();
|
|
|
|
CpuMpPpi = CpuFeaturesData->MpService.Ppi;
|
2017-04-05 10:33:16 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Get the number of CPUs
|
|
|
|
//
|
|
|
|
Status = CpuMpPpi->GetNumberOfProcessors (
|
|
|
|
GetPeiServicesTablePointer (),
|
|
|
|
CpuMpPpi,
|
|
|
|
NumberOfCpus,
|
|
|
|
NumberOfEnabledProcessors
|
|
|
|
);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
}
|
UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type.
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>
2018-10-17 03:31:03 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
Performs CPU features Initialization.
|
|
|
|
|
|
|
|
This service will invoke MP service to perform CPU features
|
|
|
|
initialization on BSP/APs per user configuration.
|
|
|
|
|
|
|
|
@note This service could be called by BSP only.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
CpuFeaturesInitialize (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
CPU_FEATURES_DATA *CpuFeaturesData;
|
|
|
|
UINTN OldBspNumber;
|
|
|
|
|
|
|
|
CpuFeaturesData = GetCpuFeaturesData ();
|
|
|
|
|
2019-01-04 06:37:29 +01:00
|
|
|
OldBspNumber = GetProcessorIndex (CpuFeaturesData);
|
UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type.
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>
2018-10-17 03:31:03 +02:00
|
|
|
CpuFeaturesData->BspNumber = OldBspNumber;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Known limitation: In PEI phase, CpuFeatures driver not
|
|
|
|
// support async mode execute tasks. So semaphore type
|
|
|
|
// register can't been used for this instance, must use
|
|
|
|
// DXE type instance.
|
|
|
|
//
|
|
|
|
|
2019-07-10 13:40:05 +02:00
|
|
|
if (CpuFeaturesData->NumberOfCpus > 1) {
|
|
|
|
//
|
|
|
|
// Wakeup all APs for programming.
|
|
|
|
//
|
|
|
|
StartupAPsWorker (SetProcessorRegister, NULL);
|
|
|
|
}
|
|
|
|
|
UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type.
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>
2018-10-17 03:31:03 +02:00
|
|
|
//
|
|
|
|
// Programming BSP
|
|
|
|
//
|
|
|
|
SetProcessorRegister (CpuFeaturesData);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Switch to new BSP if required
|
|
|
|
//
|
|
|
|
if (CpuFeaturesData->BspNumber != OldBspNumber) {
|
|
|
|
SwitchNewBsp (CpuFeaturesData->BspNumber);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|