From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 B8D1581EE3 for ; Tue, 15 Nov 2016 05:35:29 -0800 (PST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP; 15 Nov 2016 05:35:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,495,1473145200"; d="scan'208,217";a="31184755" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga004.jf.intel.com with ESMTP; 15 Nov 2016 05:35:33 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 15 Nov 2016 05:35:33 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.239]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id 14.03.0248.002; Tue, 15 Nov 2016 21:35:31 +0800 From: "Fan, Jeff" To: "Gao, Liming" , Laszlo Ersek , "edk2-devel@ml01.01.org" CC: Paolo Bonzini , "Yao, Jiewen" , "Tian, Feng" , "Kinney, Michael D" Thread-Topic: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Add volatile for mNumberToFinish Thread-Index: AQHSPufVurfCU4LRO0OU3IMXQC7FbaDZUy1wgAAEuYCAALPTYA== Date: Tue, 15 Nov 2016 13:35:30 +0000 Message-ID: <542CF652F8836A4AB8DBFAAD40ED192A4A2DDEDD@shsmsx102.ccr.corp.intel.com> References: <20161115021839.3984-1-jeff.fan@intel.com> <20161115021839.3984-2-jeff.fan@intel.com> <542CF652F8836A4AB8DBFAAD40ED192A4A2DD5E1@shsmsx102.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14B4B341C@shsmsx102.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14B4B341C@shsmsx102.ccr.corp.intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGM5OTg4NDgtMDVjMS00NzlhLWExMjktOWFlZjBhMjdjYWYwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InZqc1pPelgralwvSWs0SnlqN2RONGowODdPbjRsSFZWbndVQVgwN0FmVGxJPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Add volatile for mNumberToFinish X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 13:35:29 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Liming, I think so. Some internal functions in MdePkg\Library\BaseSynchronizationLi= b is just using volatile for input parameter. For example, UINT32 EFIAPI InternalSyncIncrement ( IN volatile UINT32 *Value ); Thanks! Jeff From: Gao, Liming Sent: Tuesday, November 15, 2016 6:49 PM To: Fan, Jeff; Laszlo Ersek; edk2-devel@ml01.01.org Cc: Paolo Bonzini; Yao, Jiewen; Tian, Feng; Kinney, Michael D Subject: RE: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Add volatile for mNumberToF= inish Jeff: From those API design point, does they expect the input parameter is vola= tile? If yes, I agree this change. Thanks Liming From: Fan, Jeff Sent: Tuesday, November 15, 2016 11:03 AM To: Laszlo Ersek >; edk2-devel@= ml01.01.org Cc: Paolo Bonzini >; Yao, J= iewen >; Tian, Feng >; Kinney, Michael D >; Gao, Liming > Subject: RE: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Add volatile for mNumberToF= inish Laszlo, I agree to separate another patch to change the prototype of TransferApToSa= feState() to reduce one cast operation. I will create v2 for it. I also agree updating prototype of InterlockedDecrement() is compatible upd= ating. But there are other 5 APIs as blow: InterlockedIncrement() InterlockedCompareExchange16() InterlockedCompareExchange32() InterlockedCompareExchange64() InterlockedCompareExchangePointer() To be consistence, we may need to update them together. Liming & MIke, any comments on this updating. Thanks! Jeff -----Original Message----- From: Laszlo Ersek [mailto:lersek@redhat.com] Sent: Tuesday, November 15, 2016 10:27 AM To: Fan, Jeff; edk2-devel@ml01.01.org Cc: Paolo Bonzini; Yao, Jiewen; Tian, Feng; Kinney, Michael D Subject: Re: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Add volatile for mNumberToF= inish On 11/15/16 03:18, Jeff Fan wrote: > The GCC 5.4 will optimize mNumberToFinish in EarlyInitializeCpu(). It > will cause > S3 resume failure. > > Adding *volatile* could make sure compiler does not so such optimization. > > Cc: Paolo Bonzini > Cc: Laszlo Ersek > Cc: Jiewen Yao > Cc: Feng Tian > Cc: Michael D Kinney > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jeff Fan > --- > UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c > b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c > index 3fb6864..f13ff3e 100644 > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c > @@ -55,7 +55,7 @@ AsmGetAddressMap ( > #define LEGACY_REGION_BASE (0xA0000 - LEGACY_REGION_SIZE) > > ACPI_CPU_DATA mAcpiCpuData; > -UINT32 mNumberToFinish; > +volatile UINT32 mNumberToFinish; > MP_CPU_EXCHANGE_INFO *mExchangeInfo; > BOOLEAN mRestoreSmmConfigurationInS3 =3D FALSE; > VOID *mGdtForAp =3D NULL; > @@ -371,7 +371,7 @@ EarlyMPRendezvousProcedure ( > // > // Count down the number with lock mechanism. > // > - InterlockedDecrement (&mNumberToFinish); > + InterlockedDecrement ((UINT32 *) &mNumberToFinish); > } > > /** > @@ -406,7 +406,7 @@ MPRendezvousProcedure ( > TopOfStack =3D (UINT32) (UINTN) Stack + sizeof (Stack); > TopOfStack &=3D ~(UINT32) (CPU_STACK_ALIGNMENT - 1); > CopyMem ((VOID *) (UINTN) mApHltLoopCode, mApHltLoopCodeTemplate, > sizeof (mApHltLoopCodeTemplate)); > - TransferApToSafeState ((UINT32) (UINTN) mApHltLoopCode, TopOfStack, > &mNumberToFinish); > + TransferApToSafeState ((UINT32) (UINTN) mApHltLoopCode, TopOfStack, > + (UINT32 *) &mNumberToFinish); > } > > /** > I think I understand the idea, but the current solution requires you to cas= t away "volatile" in two places. That's not nice, normally it is undefined = behavior. I recommend to extend this patch, with more patches: please change the prot= otype of TransferApToSafeState() so that it takes a pointer-to-volatile. I also suggest to change the prototype of InterlockedDecrement(). (You won'= t have to update all other call sites: it is fine to take/access a non-vola= tile object as a volatile, but not the other way around.) I agree this increases the scope of the patch quite a bit, so maybe others = should chime in as well. Thanks! Laszlo