From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=ray.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 40A0F211D231F for ; Tue, 5 Mar 2019 00:33:48 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 00:33:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,443,1544515200"; d="scan'208";a="129093386" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga008.fm.intel.com with ESMTP; 05 Mar 2019 00:33:47 -0800 Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Mar 2019 00:33:47 -0800 Received: from shsmsx107.ccr.corp.intel.com (10.239.4.96) by fmsmsx120.amr.corp.intel.com (10.18.124.208) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Mar 2019 00:33:46 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.74]) by SHSMSX107.ccr.corp.intel.com ([169.254.9.252]) with mapi id 14.03.0415.000; Tue, 5 Mar 2019 16:33:44 +0800 From: "Ni, Ray" To: "Dong, Eric" , "edk2-devel@lists.01.org" Thread-Topic: [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up Buffer. Thread-Index: AQHU0vgonTURy4K/SEuOanJNq49UkaX8tBnQ Date: Tue, 5 Mar 2019 08:33:44 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C05EC14@SHSMSX104.ccr.corp.intel.com> References: <20190305020658.23408-1-eric.dong@intel.com> <20190305020658.23408-2-eric.dong@intel.com> In-Reply-To: <20190305020658.23408-2-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 Subject: Re: [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up Buffer. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 08:33:49 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, I agree with the code change. It fixes the memtest86 problem through a very simple code change. But I think we do need a very meaningful comments to describe a such simple code change. Comments below: 1. Please make sure each line of commit message doesn't exceed 70. > -----Original Message----- > From: Dong, Eric > Sent: Tuesday, March 5, 2019 10:07 AM > To: edk2-devel@lists.01.org > Cc: Ni, Ray > Subject: [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up > Buffer. >=20 > https://bugzilla.tianocore.org/show_bug.cgi?id=3D1538 >=20 > Current CpuDxe driver "borrows" Wakeup Buffer (through Allocate & free > to get the buffer pointer, backup the buffer data before using it and > restore it after using). Now this logic met a problem described in > the above BZ because the test tool and the CpuDxe both use the same > memory at the same time. 2. Can you describe the issue more clearly in the commit message? What problem is met? What's the tool? >=20 > In order to fix the above issue, CpuDxe changed to allocate the buffer > below 1M instead of borrow it. After investigation, we found below > 0x88000 is the possible space which can be used.=20 3. What investigation was made to choose 0x88000? > For now, range > 0x60000 ~ 0x88000 used for Legacy OPROMs by LegacyBios driver. And it > tries to allocate these range page(4K size) by page. It just reports > warning message if specific page been used by others already. >=20 > Also CpuDxe driver will produce CPU arch protocol and LegacyBios driver > has dependency for this protocol. So CpuDxe driver will start before > LegacyBios driver and CpuDxe driver can allocate that space successful. >=20 > With this change, CpuDxe driver will use 0x87000 ~ 0x88000 as wakeup > buffer. 4. What if someone allocates the exact page? Will CpuDxe driver fail to sta= rt? >=20 > Cc: Ray Ni > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Eric Dong > --- > UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 30 +++++++++++++++++++---- > ------- > 1 file changed, 19 insertions(+), 11 deletions(-) >=20 > diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c > b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c > index b2307cbb61..5bc9a47efb 100644 > --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c > +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c > @@ -76,7 +76,7 @@ SaveCpuMpData ( > } >=20 > /** > - Get available system memory below 1MB by specified size. > + Get available system memory below 0x88000 by specified size. >=20 > @param[in] WakeupBufferSize Wakeup buffer size required >=20 > @@ -91,7 +91,19 @@ GetWakeupBuffer ( > EFI_STATUS Status; > EFI_PHYSICAL_ADDRESS StartAddress; >=20 > - StartAddress =3D BASE_1MB; > + // > + // Current "Borrow" space mechanism caused potential race condition if > both > + // AP and the original owner use the share space. > + // 5. future code reader cannot understand what "current borrow mechanism" bec= ause you change the implementation. > + // LegacyBios driver tries to allocate 4K pages between 0x60000 ~ 0x88= 000 > + // space. It will just report an waring message if the page has been a= llocate > + // by other drivers. 6. The above wording describes the behavior of LegacyBios driver. What's th= e relation ship between the LegacyBios driver behavior and the new implementa= tion? > + // LagacyBios driver depends on CPU Arch protocol, so it will start af= ter > + // CpuDxe driver which produce Cpu Arch Protocol and use this library. > + // So below allocate logic will be trigged before LegacyBios driver an= d it > + // will always return success. > + // > + StartAddress =3D BASE_512KB + BASE_32KB; 7. If 0x88000 is chosen, why use BASE_512KB + BASE_32KB instead of 0x88000? Will you remove the hard-code 0x88000 and use BASE_1MB after CSM is EOL? > Status =3D gBS->AllocatePages ( > AllocateMaxAddress, > EfiBootServicesData, > @@ -99,17 +111,13 @@ GetWakeupBuffer ( > &StartAddress > ); > ASSERT_EFI_ERROR (Status); > - if (!EFI_ERROR (Status)) { > - Status =3D gBS->FreePages( > - StartAddress, > - EFI_SIZE_TO_PAGES (WakeupBufferSize) > - ); > - ASSERT_EFI_ERROR (Status); > - DEBUG ((DEBUG_INFO, "WakeupBufferStart =3D %x, WakeupBufferSize > =3D %x\n", > - (UINTN) StartAddress, WakeupBufferSize)); > - } else { > + if (EFI_ERROR (Status)) { > StartAddress =3D (EFI_PHYSICAL_ADDRESS) -1; > } > + > + DEBUG ((DEBUG_INFO, "WakeupBufferStart =3D %x, WakeupBufferSize > =3D %x\n", > + (UINTN) StartAddress, WakeupBufferSize)); > + > return (UINTN) StartAddress; > } >=20 > -- > 2.15.0.windows.1