public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ayush Singh" <ayushdevel1325@gmail.com>
To: edk2-devel-groups-io <devel@edk2.groups.io>,
	Nate DeSimone <nathaniel.l.desimone@intel.com>
Subject: Re: [edk2-devel] Clarification of Memory management in PEI phase
Date: Thu, 23 Jun 2022 11:00:34 +0530	[thread overview]
Message-ID: <CA+Yfj7vDaYjEYs0Zuix6wbyrn1Bo6p0drtM46WNyqwov16AcxQ@mail.gmail.com> (raw)
In-Reply-To: <MW4PR11MB5821EA4532A3A8E2DB551AE2CDB29@MW4PR11MB5821.namprd11.prod.outlook.com>

Hello everyone, Thanks for the helpful answers.

After discussion with the mentors, it was decided that we should first
get the Rust std to work in DXE phase. So for now, that is the goal.
Once DXE is complete and there is still time left (or I can just do it
after GSoC as well), then I might look into implementing std for the
PEI.

Yours Sincerely
Ayush Singh

On Thu, Jun 23, 2022 at 4:28 AM Nate DeSimone
<nathaniel.l.desimone@intel.com> wrote:
>
> Hi Ayush,
>
>
>
> For your work to make Rust run in PEI I would recommend writing a generic heap manager that uses the PEI services AllocatePage() and FreePage(). PEI does allow you to truly free up memory but only when allocated in 4KB increments. Your heap manager can allow the Rust program to go to a smaller granularity.
>
>
>
> In parallel, I can see merit in the argument for adding proper heap management to PEI, but that would be a PI specification update that is way outside the scope of your GSoC project and won’t happen fast enough for the work you need to do this summer 😊.
>
>
>
> Thanks,
>
> Nate
>
>
>
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ayush Singh
> Sent: Thursday, June 9, 2022 10:23 PM
> To: Andrew Fish <afish@apple.com>
> Cc: devel@edk2.groups.io
> Subject: Re: [edk2-devel] Clarification of Memory management in PEI phase
>
>
>
> Thanks for the wonderful answer.
>
>
>
> Ayush Singh
>
>
> On Thu, Jun 9 2022 at 01:26:58 PM -0700, Andrew Fish <afish@apple.com> wrote:
>
> On Jun 9, 2022, at 10:28 AM, Ayush Singh <ayushdevel1325@gmail.com> 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()
>
> 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.
>
> 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?
>
> 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ā��t 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/Memory/MemoryServices.c#L878 Thanks, Andrew Fish
>
> Ayush Singh
>
> 

      parent reply	other threads:[~2022-06-23  5:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09 17:28 Clarification of Memory management in PEI phase Ayush Singh
2022-06-09 20:26 ` [edk2-devel] " Andrew Fish
2022-06-10  5:22   ` Ayush Singh
2022-06-22 19:39     ` Brian J. Johnson
2022-06-22 20:54       ` Andrew Fish
2022-06-22 21:41         ` Brian J. Johnson
2022-06-22 21:59           ` vincent zimmer
2022-07-01 17:00             ` FreePool in PEI (was: Clarification of Memory management in PEI phase) Brian J. Johnson
2022-06-22 22:58     ` [edk2-devel] Clarification of Memory management in PEI phase Nate DeSimone
2022-06-23  0:10       ` Michael Kubacki
2022-06-23  5:30       ` Ayush Singh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+Yfj7vDaYjEYs0Zuix6wbyrn1Bo6p0drtM46WNyqwov16AcxQ@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox