From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by mx.groups.io with SMTP id smtpd.web12.490.1655935174536373120 for ; Wed, 22 Jun 2022 14:59:34 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ptlfF2T0; spf=pass (domain: gmail.com, ip: 209.85.219.45, mailfrom: vincent.zimmer@gmail.com) Received: by mail-qv1-f45.google.com with SMTP id t16so22253173qvh.1 for ; Wed, 22 Jun 2022 14:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=3uXOufGayozLxd/9x3j08/2vFd1Or+Q8GQCPHouOhhE=; b=ptlfF2T0xJDLsi3uqOyDwW3iRcDY3QlK8U34cP7jPRLVlizJgaB13AF2Su1EhTgvzd 7HnrmNN/MBMGqpMIsYizh20Sij3EWecE73QjQ8nkYowgvf6gVzbu3vtYzozwbt+QgKNC +QRCVQ4rIeVS576uuMuue70SqgPxKNdx7r7+GKJWGrmkE/I208N9ZTBVM4U6vamTc+UO vtVZDZUZ46QzVLo8BgfLwg0fqpVBVhaOkUOq/Ln5RiOby0NjERrLeU4SXu73lIoMnBqf m+/4rRkDvWXyV+Q4jLT3ZBK3PK/D6S+48C60CKSxETha7pFPsWULU6q103r8RFvkYfob EHSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=3uXOufGayozLxd/9x3j08/2vFd1Or+Q8GQCPHouOhhE=; b=tSSVluUIMrdyNd4fihLn+3yLJa6tv6Q5Hn2KyYFAjwzvmCF0HyQd9v6lzNEwAC3mdx F6in16nleU2T6YRmTKFtWOCPjlXlQZNkUZE5CJWJRFu1M4kVhYxl7+D+wH5rCwynkZwl HE5KONvelV9zzhXOk8RRf2XeFG54p6VPlDZiIp2RNs7d36PadNURgb6bI/uvhvEuo1h5 VRtdFbDRRey3Y37ON+0hZTHSHAsJ2yUKcjyb/NEg7SH5ajOQ8R87Nro1RZhwXeFsH8P9 KCRINGAXQDw7d3pBmCfm3r7XIMZBE3qXybqgCYpon+lNckHdtkId0pv5S52Tki/tfxTa kwcg== X-Gm-Message-State: AJIora+VnaZst+7Y3gYN+VEDh3ycZOkDVK9b0XpLclGrReRyJnIZO6Jc XPzdvVcMKkoDANpxVoVk0KdDrOOidMkdngEcNJDPU8HBrmk= X-Google-Smtp-Source: AGRyM1veCQVDZGyhNRmRIoUc9XAm1L3gioM1BJ8JLaUjemVmAydf/gIiocx5oMSOSE7P9i/NJTb1qaRj7mobfa1qV5M= X-Received: by 2002:a05:622a:1829:b0:304:ef78:8385 with SMTP id t41-20020a05622a182900b00304ef788385mr5169744qtc.251.1655935173410; Wed, 22 Jun 2022 14:59:33 -0700 (PDT) MIME-Version: 1.0 References: <500949D4-FFB9-4BC1-8655-430BC788765A@apple.com> <76b8a649-c0e1-8ee8-4502-8d6010a76b14@hpe.com> <64A70BD6-B1A0-4DDC-8B41-40222258F1EB@apple.com> <9e98ae48-41c5-18c3-d347-2a5312e111b3@hpe.com> In-Reply-To: <9e98ae48-41c5-18c3-d347-2a5312e111b3@hpe.com> From: "vincent zimmer" Date: Wed, 22 Jun 2022 14:59:24 -0700 Message-ID: Subject: Re: [edk2-devel] Clarification of Memory management in PEI phase To: devel@edk2.groups.io, brian.johnson@hpe.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable sounds like a good idea. As a next step, perhaps a candidate activity for https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First= -Process in anticipation of future inclusion in PI? Vincent On Wed, Jun 22, 2022 at 2:41 PM Brian J. Johnson wr= ote: > > Andrew, > > Yes, adding a new HOB type to represent free pool would probably be the e= asiest. > > Or we could write or borrow a traditional malloc() implementation, simila= r to DXE's pool allocator, and back it with memory from AllocatePages(). T= hat would probably have better performance, and would avoid fragmenting the= pool memory when non-pool HOBs are added. It would probably be more code,= though. > > Brian J. Johnson > ________________________________ > From: Andrew Fish [mailto:afish@apple.com] > Sent: Wednesday, June 22, 2022, 3:54 PM > To: Brian J. Johnson > Cc: devel@edk2.groups.io, ayushdevel1325@gmail.com > Subject: [edk2-devel] Clarification of Memory management in PEI phase > > Brian, > > I think all the PEI Allocate Pool does is make a HOB [1]. I don=E2=80=99t= think we can remove HOBs when memory is freed as that would change pointe= rs to pool. It may be possible to mark a region as free and allocate from t= hat list batch 1st, and just over allocate space if needed. It could be as = simple as just adding a new HOB type to represent free pool. > > > [1] https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/M= emory/MemoryServices.c#L878 > > Thanks, > > Andrew Fish > > On Jun 22, 2022, at 12:39 PM, Brian J. Johnson > Sorry for the late response to this thread... > > PEI has grown greatly in complexity, as Andrew pointed out. Do we (Tiano= Core community) think it's time to add a real pool manager to PEI? There's= getting to be quite a bit of post-DRAM-initialization PEI code on some pla= tforms. And really, having a limited amount of pre-DRAM memory available i= s an even better reason for having an effective pool allocator, so the memo= ry can be freed and reused. > > FWIW we (HPE) needed to add a private pool allocator to manage memory for= a proprietary h/w initialization module which needs to run in post-DRAM PE= I, and depends on allocating and freeing memory in different phases of its = operation. > > Brian J. Johnson > > ________________________________ > From: Ayush Singh [mailto:ayushdevel1325@gmail.com] > Sent: Friday, June 10, 2022, 12:22 AM > To: Andrew Fish > Cc: devel@edk2.groups.io > Subject: [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 wr= ote: > > On Jun 9, 2022, at 10:28 AM, Ayush Singh > This is basically: (*PeiServices)->InstallPeiMemory (PeiServices, MemoryB= egin, 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. FreePage= s() However, no `FreePool()` service seems to be present. So how is the mem= ory allocated using `AllocatePool()` freed? > > It basically gets Freed when you transition to the DXE phase. To step bac= k 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 yo= u can load the DXE Phase and start up EFI. Remember PEI is Pre EFI. The rea= lity 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 ne= ver the intent. PEI is designed as a way to run C code when you code is run= ning from ROM and you don=C4=81=EF=BF=BD=EF=BF=BDt have any DRAM. For x86 n= ot 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 des= igned 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 alloca= tion in PEI is just a HOB. See [1]. There is no way to free a HOB. So the A= llocatePool() kind of leaks into DXE too as an entry in the HOB list. But w= hen the OS called gBS->ExitBootServices() that frees all non runtime memory= back to the OS. If you look a AllocatePages/FreePages you will see Allocat= ePages creates a HOB that points to the memory region, and FreePages just m= arks 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/maste= r/MdeModulePkg/Core/Pei/Memory/MemoryServices.c#L878 Thanks, Andrew Fish > > Ayush Singh > > > Brian > > -------------------------------------------------------------------------= ----------------------------------------------------- > > "There is the greatest practical benefit in making a few failures > early in life." > -- Thomas Henry Huxley > >=20