Before adding another AP enumeration mode, clarify the documentation on
the current logic. No functional changes.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
Notes:
v2:
- new patch
UefiCpuPkg/Library/MpInitLib/MpLib.c | 38 +++++++++++++++-----
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index d6f84c6f45c0..594a035d8b92 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -1045,14 +1045,36 @@ WakeUpAP (
}
if (CpuMpData->InitFlag == ApInitConfig) {
//
- // Here support two methods to collect AP count through adjust
- // PcdCpuApInitTimeOutInMicroSeconds values.
- //
- // one way is set a value to just let the first AP to start the
- // initialization, then through the later while loop to wait all Aps
- // finsh the initialization.
- // The other way is set a value to let all APs finished the initialzation.
- // In this case, the later while loop is useless.
+ // The AP enumeration algorithm below is suitable for two use cases.
+ //
+ // (1) The check-in time for an individual AP is bounded, and APs run
+ // through their initialization routines strongly concurrently. In
+ // particular, the number of concurrently running APs
+ // ("NumApsExecuting") is never expected to fall to zero
+ // *temporarily* -- it is expected to fall to zero only when all
+ // APs have checked-in.
+ //
+ // In this case, the platform is supposed to set
+ // PcdCpuApInitTimeOutInMicroSeconds to a low-ish value (just long
+ // enough for one AP to start initialization). The timeout will be
+ // reached soon, and remaining APs are collected by watching
+ // NumApsExecuting fall to zero. If NumApsExecuting falls to zero
+ // mid-process, while some APs have not completed initialization,
+ // the behavior is undefined.
+ //
+ // (2) The check-in time for an individual AP is unbounded, and/or APs
+ // may complete their initializations widely spread out. In
+ // particular, some APs may finish initialization before some APs
+ // even start.
+ //
+ // In this case, the platform is supposed to set
+ // PcdCpuApInitTimeOutInMicroSeconds to a high-ish value. The AP
+ // enumeration will always take that long (except when the boot CPU
+ // count happens to be maximal, that is,
+ // PcdCpuMaxLogicalProcessorNumber). All APs are expected to
+ // check-in before the timeout, and NumApsExecuting is assumed zero
+ // at timeout. APs that miss the time-out may cause undefined
+ // behavior.
//
TimedWaitForApFinish (
CpuMpData,
--
2.19.1.3.g30247aa5d201
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#48723): https://edk2.groups.io/g/devel/message/48723
Mute This Topic: https://groups.io/mt/34473662/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Reviewed-by: Ray Ni <ray.ni@intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Thursday, October 10, 2019 7:30 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: [PATCH v2 1/2] UefiCpuPkg/MpInitLib: expand comment on initial
> AP enumeration
>
> Before adding another AP enumeration mode, clarify the documentation on
> the current logic. No functional changes.
>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>
> Notes:
> v2:
> - new patch
>
> UefiCpuPkg/Library/MpInitLib/MpLib.c | 38 +++++++++++++++-----
> 1 file changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index d6f84c6f45c0..594a035d8b92 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1045,14 +1045,36 @@ WakeUpAP (
> }
> if (CpuMpData->InitFlag == ApInitConfig) {
> //
> - // Here support two methods to collect AP count through adjust
> - // PcdCpuApInitTimeOutInMicroSeconds values.
> - //
> - // one way is set a value to just let the first AP to start the
> - // initialization, then through the later while loop to wait all Aps
> - // finsh the initialization.
> - // The other way is set a value to let all APs finished the initialzation.
> - // In this case, the later while loop is useless.
> + // The AP enumeration algorithm below is suitable for two use cases.
> + //
> + // (1) The check-in time for an individual AP is bounded, and APs run
> + // through their initialization routines strongly concurrently. In
> + // particular, the number of concurrently running APs
> + // ("NumApsExecuting") is never expected to fall to zero
> + // *temporarily* -- it is expected to fall to zero only when all
> + // APs have checked-in.
> + //
> + // In this case, the platform is supposed to set
> + // PcdCpuApInitTimeOutInMicroSeconds to a low-ish value (just long
> + // enough for one AP to start initialization). The timeout will be
> + // reached soon, and remaining APs are collected by watching
> + // NumApsExecuting fall to zero. If NumApsExecuting falls to zero
> + // mid-process, while some APs have not completed initialization,
> + // the behavior is undefined.
> + //
> + // (2) The check-in time for an individual AP is unbounded, and/or APs
> + // may complete their initializations widely spread out. In
> + // particular, some APs may finish initialization before some APs
> + // even start.
> + //
> + // In this case, the platform is supposed to set
> + // PcdCpuApInitTimeOutInMicroSeconds to a high-ish value. The AP
> + // enumeration will always take that long (except when the boot CPU
> + // count happens to be maximal, that is,
> + // PcdCpuMaxLogicalProcessorNumber). All APs are expected to
> + // check-in before the timeout, and NumApsExecuting is assumed zero
> + // at timeout. APs that miss the time-out may cause undefined
> + // behavior.
> //
> TimedWaitForApFinish (
> CpuMpData,
> --
> 2.19.1.3.g30247aa5d201
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#48805): https://edk2.groups.io/g/devel/message/48805
Mute This Topic: https://groups.io/mt/34473662/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2026 Red Hat, Inc.