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 651A921B02845 for ; Tue, 22 May 2018 03:00:14 -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 5D6287DAC1; Tue, 22 May 2018 10:00:13 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-18.rdu2.redhat.com [10.10.120.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id B5620215CDA7; Tue, 22 May 2018 10:00:11 +0000 (UTC) To: "Zeng, Star" , Ard Biesheuvel Cc: "Bi, Dandan" , Andrew Fish , "Kinney, Michael D" , Leif Lindholm , "edk2-devel@lists.01.org" , "Gao, Liming" , Matt Sealey References: <1517320437-11688-1-git-send-email-dandan.bi@intel.com> <1517320437-11688-4-git-send-email-dandan.bi@intel.com> <3C0D5C461C9E904E8F62152F6274C0BB3BAD755F@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BAEE227@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BAEE2BC@shsmsx102.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <7e5f817f-d2b9-1359-974c-ace751cd2984@redhat.com> Date: Tue, 22 May 2018 12:00:10 +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: <0C09AFA07DD0434D9E2A0C6AEB0483103BAEE2BC@shsmsx102.ccr.corp.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.2]); Tue, 22 May 2018 10:00:13 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 22 May 2018 10:00:13 +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 v2 3/8] MdeModulePkg/DxeCorePerformanceLib:Track FPDT record in DXE phase 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: Tue, 22 May 2018 10:00:14 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Star, On 05/22/18 11:38, Zeng, Star wrote: > It comes to an old question: how to know PEI is 32bit/64bit? But not DXE is 32bit/64bit. we've discussed this question in the past (as you remember :) ) and people suggested both HOBs and PCDs to expose the "PEI phase max address" to DXE. All of those ideas were rejected -- I'm unsure why, to this day --, but assuming people who opposed those ideas are going to oppose them again, I think Ard's idea is good, about introducing dedicated MemoryAllocationLib interfaces, for PEI-targeted memory allocation. Once drivers adopt these new interfaces, platforms can at least fork the MemoryAllocationLib instance(s) they need, and customize the PEI phase max address one way or another. Thanks, Laszlo > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Tuesday, May 22, 2018 5:03 PM > To: Zeng, Star > Cc: Bi, Dandan ; Laszlo Ersek ; Andrew Fish ; Kinney, Michael D ; Leif Lindholm ; edk2-devel@lists.01.org; Gao, Liming ; Matt Sealey > Subject: Re: [edk2] [PATCH v2 3/8] MdeModulePkg/DxeCorePerformanceLib:Track FPDT record in DXE phase > > pd On 22 May 2018 at 10:58, Zeng, Star wrote: >> How about the code to try allocating <4G memory, then try allocating any memory if failed to allocate <4G memory? >> >> For example, the code snippet in SmbiosDxe.c. >> >> PhysicalAddress = 0xffffffff; >> Status = gBS->AllocatePages ( >> AllocateMaxAddress, >> EfiRuntimeServicesData, >> EFI_SIZE_TO_PAGES (sizeof (SMBIOS_TABLE_ENTRY_POINT)), >> &PhysicalAddress >> ); >> if (EFI_ERROR (Status)) { >> DEBUG ((EFI_D_ERROR, "SmbiosCreateTable () could not allocate EntryPointStructure < 4GB\n")); >> Status = gBS->AllocatePages ( >> AllocateAnyPages, >> EfiRuntimeServicesData, >> EFI_SIZE_TO_PAGES (sizeof (SMBIOS_TABLE_ENTRY_POINT)), >> &PhysicalAddress >> ); >> if (EFI_ERROR (Status)) { >> return EFI_OUT_OF_RESOURCES; >> } >> } >> > > Yes, that should do the trick. > > But perhaps we should add something like > > AllocatePeiAccessiblePages() > > to MemoryAllocationLib, which just uses AllocateMaxAddress or > AllocateAnyPages depending on whether MDE_CPU_X64 is #defined. >