From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx.groups.io with SMTP id smtpd.web09.5953.1576822507223475408 for ; Thu, 19 Dec 2019 22:15:07 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.88, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2019 22:15:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,334,1571727600"; d="scan'208";a="222435718" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga001.fm.intel.com with ESMTP; 19 Dec 2019 22:15:06 -0800 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 19 Dec 2019 22:15:06 -0800 Received: from shsmsx154.ccr.corp.intel.com (10.239.6.54) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 19 Dec 2019 22:15:05 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.90]) by SHSMSX154.ccr.corp.intel.com ([169.254.7.71]) with mapi id 14.03.0439.000; Fri, 20 Dec 2019 14:15:04 +0800 From: "Ni, Ray" To: "Dong, Eric" , "devel@edk2.groups.io" CC: Laszlo Ersek Subject: Re: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Remove dependence between APs. Thread-Topic: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Remove dependence between APs. Thread-Index: AQHVtvc2wSVTWG3sVUGFNGZQYZuh+6fCh8iQ Date: Fri, 20 Dec 2019 06:15:03 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C3A3FA1@SHSMSX104.ccr.corp.intel.com> References: <20191220053446.1532-1-eric.dong@intel.com> In-Reply-To: <20191220053446.1532-1-eric.dong@intel.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: ray.ni@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >=20 > + if (!Token->SingleAp) { >=20 > + ReleaseSemaphore (&Token->FinishedApCount); 1. If the FinishedApCount is renamed to RunningApCount and InterlockedDecrement() is called for it. SingleAp flag is unneeded. For StartupAllAps(), RunningApCount =3D mMaxNumberOfCpus - 1; For StartupThisAps(), RunningApCount =3D 1; When RunningApCount =3D=3D 0, the spinlock is released. > + if (mSmmMpSyncData->CpuData[CpuIndex].Token !=3D NULL) { >=20 > + ReleaseToken (CpuIndex); 2. Can you directly pass in mSmmMpSyncData->CpuData[CpuIndex].Token? It simplifies the ReleaseToken() and also make people understand that ReleaseToken() will only modifies the Token but other states in CpuData[Ind= ex] is NOT changed. >=20 > @@ -1170,10 +1120,12 @@ CreateToken ( 3. With the comment #1, CreateToken() can carry additional parameter which = specifies the RunningApCount. > ASSERT (ProcToken !=3D NULL); >=20 > ProcToken->Signature =3D PROCEDURE_TOKEN_SIGNATURE; >=20 > ProcToken->ProcedureToken =3D CpuToken; 4. ProcToken->ProcedureToken looks a bit strange. Can we use "ProcToken->Spinlock"? >=20 > + *Token =3D (MM_COMPLETION) mSmmMpSyncData- > >CpuData[CpuIndex].Token->ProcedureToken; 5. It will become *Token =3D (MM_COMPLETION) mSmmMpSyncData->CpuData[CpuIndex].Token->Spinloc= k; >=20 > + ReleaseSemaphore (&ProcToken->FinishedApCount); 6. I can now understand why "FinishedApCount is directly compared against m= MaxNumberOfCpus because the FinishedApCount is already increased for BSP. It's not a comment for co= de change. Thanks, Ray