From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web11.1781.1655943006218014754 for ; Wed, 22 Jun 2022 17:10:06 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@linux.microsoft.com header.s=default header.b=HDscdxM3; spf=pass (domain: linux.microsoft.com, ip: 13.77.154.182, mailfrom: mikuback@linux.microsoft.com) Received: from [192.168.4.22] (unknown [47.195.228.134]) by linux.microsoft.com (Postfix) with ESMTPSA id 586BB20C637C; Wed, 22 Jun 2022 17:10:05 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 586BB20C637C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1655943005; bh=pAGQPtwSsDDtH/llpt4ommxUwQFunNBOBiLOlfDAA7A=; h=Date:Subject:To:References:From:In-Reply-To:From; b=HDscdxM3Nnw4t7j7PvZ7r5vQhGv136iNrmT4shA0OMCc7VaGcJdaY3eqsJAAxuJ6d YBG3G9oID7aSxS9SbEWb660JCJ8VhOWEumqj5DAhW49Dm0jc4KFUSMFZcExR/CTNzH aEgE6sYEhAi14i75xi8/vnCCC+JD4aJJoFxHQESw= Message-ID: <295c8f7e-92bf-a86e-a930-1d5244f4e59a@linux.microsoft.com> Date: Wed, 22 Jun 2022 20:10:04 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [edk2-devel] Clarification of Memory management in PEI phase To: devel@edk2.groups.io, nathaniel.l.desimone@intel.com, "ayushdevel1325@gmail.com" , Andrew Fish References: <500949D4-FFB9-4BC1-8655-430BC788765A@apple.com> From: "Michael Kubacki" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I agree with other comments here. I mainly want to add that if you're=20 new to PI/UEFI, you might find the following resource helpful for tying=20 together some pieces from the code and documents like the PI Spec. https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyon= d_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf Thanks, Michael On 6/22/2022 6:58 PM, Nate DeSimone wrote: > Hi Ayush, >=20 > For your work to make Rust run in PEI I would recommend writing a=20 > generic heap manager that uses the PEI services AllocatePage() and=20 > FreePage(). PEI does allow you to truly free up memory but only when=20 > allocated in 4KB increments. Your heap manager can allow the Rust=20 > program to go to a smaller granularity. >=20 > In parallel, I can see merit in the argument for adding proper heap=20 > management to PEI, but that would be a PI specification update that is=20 > way outside the scope of your GSoC project and won=E2=80=99t happen fast = enough=20 > for the work you need to do this summer =F0=9F=98=8A. >=20 > Thanks, >=20 > Nate >=20 > *From:* devel@edk2.groups.io *On Behalf Of *Ayush= =20 > Singh > *Sent:* Thursday, June 9, 2022 10:23 PM > *To:* Andrew Fish > *Cc:* devel@edk2.groups.io > *Subject:* Re: [edk2-devel] Clarification of Memory management in PEI pha= se >=20 > Thanks for the wonderful answer. >=20 > Ayush Singh >=20 >=20 > On Thu, Jun 9 2022 at 01:26:58 PM -0700, Andrew Fish > wrote: >=20 > On Jun 9, 2022, at 10:28 AM, Ayush Singh > > > wrote: Hello everyone, Can anyone help me with understanding > dynamic memory management in PEI phase? In the UEFI Platform > Integration Specification, version 1.7 Errata A, Section 4.6, > PEI Memory services are given which include: 1. InstallPeiMemory(= ) >=20 > This is basically: (*PeiServices)->InstallPeiMemory (PeiServices, > MemoryBegin, MemoryLength); This is how you tell the PEI Core the > location of the memory that will can be used in PEI. >=20 > 2. AllocatePages() 3. AllocatePool() 4. CopyMem() 5. SetMem() 6. > FreePages() However, no `FreePool()` service seems to be > present. So how is the memory allocated using `AllocatePool()` > freed? >=20 > It basically gets Freed when you transition to the DXE phase. To > step back for a minute I think it is important to remember that the > main job of PEI is to initialize DRAM, and deal with S3 (resuming > from suspend to RAM). So as soon as you have DRAM you are kind done > and ready for the DXE IPL so you can load the DXE Phase and start up > EFI. Remember PEI is Pre EFI. The reality is programming DRAM is > complex and lots of code got written, then lots more code got > written and PEI has become large for some ports. That was never the > intent. PEI is designed as a way to run C code when you code is > running from ROM and you don=C4=81=EF=BF=BD=EF=BF=BDt have any DRAM. = For x86 not having > DRAM means you are using the cache as RAM. For some SoCs there is > actually an SRAM you can use. Thus the PEI memory allocation scheme > is designed to deal with this very constrained environment. You > start PEI with a heap and stack. You can also allocate HOBs (Hand > Off Blocks). A pool allocation in PEI is just a HOB. See [1]. There > is no way to free a HOB. So the AllocatePool() kind of leaks into > DXE too as an entry in the HOB list. But when the OS called > gBS->ExitBootServices() that frees all non runtime memory back to > the OS. If you look a AllocatePages/FreePages you will see > AllocatePages creates a HOB that points to the memory region, and > FreePages just marks that HOB as not used. That code is also in this > file [1]. TL;DR there is no pool manager in PEI. [1] > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/M= emory/MemoryServices.c#L878 > > Thanks, Andrew Fish >=20 > Ayush Singh >=20 >=20