From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8BEB6211F886C for ; Thu, 28 Jun 2018 08:37:04 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A6C5380401B6; Thu, 28 Jun 2018 15:37:03 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-10.rdu2.redhat.com [10.10.120.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id E8B5A2142F20; Thu, 28 Jun 2018 15:37:02 +0000 (UTC) To: Eric Dong , edk2-devel@lists.01.org Cc: Ruiyu Ni References: <20180628112920.5296-1-eric.dong@intel.com> <20180628112920.5296-2-eric.dong@intel.com> From: Laszlo Ersek Message-ID: <54d09d35-86c5-1f93-08ea-c01fff5cc8dd@redhat.com> Date: Thu, 28 Jun 2018 17:37:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180628112920.5296-2-eric.dong@intel.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 28 Jun 2018 15:37:03 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 28 Jun 2018 15:37:03 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [Patch 2/2] UefiCpuPkg/MpInitLib: Remove redundant parameter. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 15:37:04 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Eric, On 06/28/18 13:29, Eric Dong wrote: > Parameter StartCount duplicates with RunningCount. After this change, > RunningCount means the running AP count. > > Done Tests: > 1.PI SCT Test > 2.Boot OS / S3 > > Cc: Ruiyu Ni > Cc: Jeff Fan > Cc: Laszlo Ersek > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Eric Dong > --- > UefiCpuPkg/Library/MpInitLib/MpLib.c | 11 +++++------ > UefiCpuPkg/Library/MpInitLib/MpLib.h | 1 - > 2 files changed, 5 insertions(+), 7 deletions(-) > > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpInitLib/MpLib.c > index 3945771764..52c9679099 100644 > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c > @@ -1400,7 +1400,7 @@ CheckAllAPs ( > // value of state after setting the it to CpuStateFinished, so BSP can safely make use of its value. > // > if (GetApState(CpuData) != CpuStateBusy) { > - CpuMpData->RunningCount ++; > + CpuMpData->RunningCount --; > CpuMpData->CpuData[ProcessorNumber].Waiting = FALSE; > > // > @@ -1425,7 +1425,7 @@ CheckAllAPs ( > // > // If all APs finish, return EFI_SUCCESS. > // > - if (CpuMpData->RunningCount == CpuMpData->StartCount) { > + if (CpuMpData->RunningCount == 0) { > return EFI_SUCCESS; > } > > @@ -1442,7 +1442,7 @@ CheckAllAPs ( > // > if (CpuMpData->FailedCpuList != NULL) { > *CpuMpData->FailedCpuList = > - AllocatePool ((CpuMpData->StartCount - CpuMpData->FinishedCount + 1) * sizeof (UINTN)); > + AllocatePool ((CpuMpData->RunningCount + 1) * sizeof (UINTN)); > ASSERT (*CpuMpData->FailedCpuList != NULL); > } > ListIndex = 0; > @@ -2121,7 +2121,7 @@ StartupAllAPsWorker ( > return EFI_NOT_STARTED; > } > > - CpuMpData->StartCount = 0; > + CpuMpData->RunningCount = 0; > for (ProcessorNumber = 0; ProcessorNumber < ProcessorCount; ProcessorNumber++) { > CpuData = &CpuMpData->CpuData[ProcessorNumber]; > CpuData->Waiting = FALSE; > @@ -2131,7 +2131,7 @@ StartupAllAPsWorker ( > // Mark this processor as responsible for current calling. > // > CpuData->Waiting = TRUE; > - CpuMpData->StartCount++; > + CpuMpData->RunningCount++; > } > } > } > @@ -2140,7 +2140,6 @@ StartupAllAPsWorker ( > CpuMpData->ProcArguments = ProcedureArgument; > CpuMpData->SingleThread = SingleThread; > CpuMpData->FinishedCount = 0; > - CpuMpData->RunningCount = 0; > CpuMpData->FailedCpuList = FailedCpuList; > CpuMpData->ExpectedTime = CalculateTimeout ( > TimeoutInMicroseconds, > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h b/UefiCpuPkg/Library/MpInitLib/MpLib.h > index 90c09fb8fb..4166734687 100644 > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h > @@ -210,7 +210,6 @@ struct _CPU_MP_DATA { > UINTN BackupBuffer; > UINTN BackupBufferSize; > > - volatile UINT32 StartCount; > volatile UINT32 FinishedCount; > volatile UINT32 RunningCount; > BOOLEAN SingleThread; > I'm currently missing a good understanding of how these counters are modified. They are all qualified "volatile", which suggests they are accessed from multiple processors. Is that correct? Here's my concern: assume we have 3 APs, and we maintain how many of them are running concurrently at any given point. Assume we start them up all at once, and then later they all finish. The modified "RunningCount" value might advance like this: AP#1 AP#2 AP#3 RunningCount comment ---- ---- ---- ------------ ---------------- 0 no AP running yet v 1 AP#1 starts | v 2 AP#2 starts | | v 3 AP#3 starts | | | 3 all APs working | ^ | 2 AP#2 finishes | ^ 1 AP#3 finishes ^ 0 AP#1 finishes, done However, the following could happen as well: AP#1 AP#2 AP#3 RunningCount comment ---- ---- ---- ------------ ---------------- 0 no AP running yet v 1 AP#1 starts ^ 0 AP#1 finishes v 1 AP#2 starts | v 2 AP#3 starts | ^ 1 AP#3 finishes ^ 0 AP#2 finishes, done In the second scheduling, we get RunningCount=0 when AP#1 finishes, even though AP#2 and AP#3 are not done (they haven't even started yet). Is this a realistic concern, or is the above scenario impossible? (I'd like to test the series after understanding this.) Actually... if the problem scenario is possible, I think it could affect the current (pre-patch) code as well. I hope I'm wrong! Thanks, Laszlo