From: "Dong, Eric" <eric.dong@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Ni, Ruiyu" <ruiyu.ni@intel.com>
Subject: Re: [Patch v3 1/3] UefiCpuPkg/MpInitLib: Remove redundant CpuStateFinished State.
Date: Wed, 25 Jul 2018 11:15:29 +0000 [thread overview]
Message-ID: <ED077930C258884BBCB450DB737E66224AC5A5B3@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <191141df-1a1a-0228-9055-86fa8982287e@redhat.com>
Hi Laszlo,
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, July 25, 2018 6:55 PM
> To: Dong, Eric <eric.dong@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>
> Subject: Re: [edk2] [Patch v3 1/3] UefiCpuPkg/MpInitLib: Remove redundant
> CpuStateFinished State.
>
> Hi Eric,
>
> On 07/25/18 09:50, Eric Dong wrote:
> > Current CPU state definition include CpuStateIdle and CpuStateFinished.
> > After investigation, current code can use CpuStateIdle to replace the
> > CpuStateFinished. It will reduce the state number and easy for maintenance.
> >
> > 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>
> > ---
> > UefiCpuPkg/Library/MpInitLib/MpLib.c | 18 ++++++++----------
> > UefiCpuPkg/Library/MpInitLib/MpLib.h | 1 -
> > 2 files changed, 8 insertions(+), 11 deletions(-)
>
> After looking over this patch, it seems that you are preserving the
> CpuStateReady enum constant, relative to:
>
> http://mid.mail-archive.com/20180628112920.5296-1-eric.dong@intel.com
>
> However, based on your analysis in
>
> http://mid.mail-
> archive.com/ED077930C258884BBCB450DB737E66224AC5A453@shsmsx102.
> ccr.corp.intel.com
>
> isn't it still possible to run into the exact same issue? (Namely, BSP thinks the
> AP has gone through Idle -> Busy -> Idle, but the AP has never actually left
> Idle?)
>
> Hm, wait, is it the case that the BSP first sets Ready, and so if the check for an
> AP returns Idle, it implies the AP must have gone through:
>
> Idle ----> Ready ----> Busy ----> Idle
>
> ?
Correct! The Ready state is begin state and the Idle is the finish state.
>
> If this is correct, can you please include the following in the commit
> message:
>
> > Before this patch, the state transitions for an AP are:
> >
> > Idle ----> Ready ----> Busy ----> Finished ----> Idle
> > [BSP] [AP] [AP] [BSP]
> >
> > After the patch, the state transitions for an AP are:
> >
> > Idle ----> Ready ----> Busy ----> Idle
> > [BSP] [AP] [AP]
>
> Do you agree?
Good suggestion, I will include this info in the commit message.
>
> I have another question:
>
> On 07/25/18 09:50, Eric Dong wrote:
> > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > index c82b985943..ff09a0e9e7 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > @@ -696,7 +696,7 @@ ApWakeupFunction (
> > }
> > }
> > }
> > - SetApState (&CpuMpData->CpuData[ProcessorNumber],
> CpuStateFinished);
> > + SetApState (&CpuMpData->CpuData[ProcessorNumber],
> > + CpuStateIdle);
> > }
> > }
> >
> > @@ -1352,18 +1352,17 @@ CheckThisAP (
> > CpuData = &CpuMpData->CpuData[ProcessorNumber];
> >
> > //
> > - // Check the CPU state of AP. If it is CpuStateFinished, then the AP has
> finished its task.
> > + // Check the CPU state of AP. If it is CpuStateIdle, then the AP has
> finished its task.
> > // Only BSP and corresponding AP access this unit of CPU Data.
> > This means the AP will not modify the
> > - // value of state after setting the it to CpuStateFinished, so BSP can safely
> make use of its value.
> > + // value of state after setting the it to CpuStateIdle, so BSP can safely
> make use of its value.
> > //
> > //
> > // If the AP finishes for StartupThisAP(), return EFI_SUCCESS.
> > //
> > - if (GetApState(CpuData) == CpuStateFinished) {
> > + if (GetApState(CpuData) == CpuStateIdle) {
> > if (CpuData->Finished != NULL) {
> > *(CpuData->Finished) = TRUE;
> > }
> > - SetApState (CpuData, CpuStateIdle);
> > return EFI_SUCCESS;
> > } else {
> > //
> > @@ -1420,14 +1419,13 @@ CheckAllAPs (
> >
> > CpuData = &CpuMpData->CpuData[ProcessorNumber];
> > //
> > - // Check the CPU state of AP. If it is CpuStateFinished, then the AP has
> finished its task.
> > + // Check the CPU state of AP. If it is CpuStateIdle, then the AP has
> finished its task.
> > // Only BSP and corresponding AP access this unit of CPU Data. This
> means the AP will not modify the
> > - // value of state after setting the it to CpuStateFinished, so BSP can
> safely make use of its value.
> > + // value of state after setting the it to CpuStateIdle, so BSP can safely
> make use of its value.
> > //
> > - if (GetApState(CpuData) == CpuStateFinished) {
> > + if (GetApState(CpuData) == CpuStateIdle) {
> > CpuMpData->RunningCount ++;
> > CpuMpData->CpuData[ProcessorNumber].Waiting = FALSE;
> > - SetApState(CpuData, CpuStateIdle);
> >
> > //
> > // If in Single Thread mode, then search for the next waiting AP for
> execution.
>
> This part of the code, after the patch, does not seem idempotent; in other
> words, if the BSP calls CheckAllAPs() multiple times, then RunningCount will
> be increased every time. Before the patch, this wasn't the case, because after
> the Finished -> Idle transition, the increment wouldn't be reached again.
>
> Hmmm, wait, I'm wrong: we set the Waiting field to FALSE as well, so at the
> next call to CheckAllAPs(), we'll take the early "continue" branch.
> Looks OK after all.
>
Yes, we have two flags here. Waiting flags means the AP will do the task. State flag means whether the task has finished.
Both flags will be checked and updated.
> I'll follow up with test results.
>
> Thanks,
> Laszlo
>
> > @@ -1923,7 +1921,7 @@ SwitchBSPWorker (
> > //
> > // Wait for old BSP finished AP task
> > //
> > - while (GetApState (&CpuMpData->CpuData[CallerNumber]) !=
> > CpuStateFinished) {
> > + while (GetApState (&CpuMpData->CpuData[CallerNumber]) !=
> > + CpuStateIdle) {
> > CpuPause ();
> > }
> >
> > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> > b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> > index 9d0b866d09..962bce685d 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> > @@ -85,7 +85,6 @@ typedef enum {
> > CpuStateIdle,
> > CpuStateReady,
> > CpuStateBusy,
> > - CpuStateFinished,
> > CpuStateDisabled
> > } CPU_STATE;
> >
> >
next prev parent reply other threads:[~2018-07-25 11:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-25 7:50 [Patch V3 0/3] StartAllAPs should not use disabled APs Eric Dong
2018-07-25 7:50 ` [Patch v3 1/3] UefiCpuPkg/MpInitLib: Remove redundant CpuStateFinished State Eric Dong
2018-07-25 10:54 ` Laszlo Ersek
2018-07-25 11:15 ` Dong, Eric [this message]
2018-07-26 5:18 ` Ni, Ruiyu
2018-07-25 7:50 ` [Patch v3 2/3] UefiCpuPkg/MpInitLib: Remove StartCount and volatile definition Eric Dong
2018-07-25 11:47 ` Laszlo Ersek
2018-07-25 12:09 ` Dong, Eric
2018-07-25 15:18 ` Laszlo Ersek
2018-07-26 5:22 ` Ni, Ruiyu
2018-07-25 7:50 ` [Patch v3 3/3] UefiCpuPkg/MpInitLib: Not use disabled AP when call StartAllAPs Eric Dong
2018-07-25 12:11 ` Laszlo Ersek
2018-07-25 12:44 ` Dong, Eric
2018-07-26 8:36 ` Ni, Ruiyu
2018-07-26 8:36 ` Ni, Ruiyu
2018-07-25 12:12 ` [Patch V3 0/3] StartAllAPs should not use disabled APs Laszlo Ersek
2018-07-25 15:18 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ED077930C258884BBCB450DB737E66224AC5A5B3@shsmsx102.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox