From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4003:c06::22a; helo=mail-oi0-x22a.google.com; envelope-from=rafaelrodrigues.machado@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3E7A3208F7CB5 for ; Tue, 7 Aug 2018 12:12:29 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id s198-v6so30355293oih.11 for ; Tue, 07 Aug 2018 12:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iU0hCekqYLHu3XHoQPXW6L4mD0Gewa3GuqZtHBlWkBA=; b=Bh+V7quFGNbehwZkB1izGxLuKns7eoQmk/CXHR9+ewshGRalGgcl5QJa9fnUmgZYmK FjGNAWPEiXN6Q01nkszuht2KD8s1m+7D2dntAFldn0krK28ZhBCIiAZaB4hblzSQt20k iwpMN9XrpJ3E6JEAhyG5B1aaXbjCDXbpS1MsZTTbODhiiZgdIdNLn25a2yMFIkpByKNf DO3pg06IIn29tdLvWmQ+Oe0ZXOF9858zHT2TY8xgzZUzl6SNLmW7/Ao5cTq9mClRgNdy ZAZ3MuHW8UxALlWLieU2/OMMaxm3Q8u6zZuxNV2r7RHCLdoT3Bs8+jEe/64UQREVIZ1A XEFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iU0hCekqYLHu3XHoQPXW6L4mD0Gewa3GuqZtHBlWkBA=; b=P0305oZUjG06Qsx6EAZGB3KmFOrQ9Niv6vrGZAMu3KxVr8R3TLqgmBCN8acMYusz8r DtdlZNVOvO9TNaSCtJ5LHfsXb80O+N9FFMnvS3J/9hHr740UzMj+wrn20dwxcaG0ZYRY UEbRVbB2zHMWOht/qpom02VEjJCFlTa9C3dBkBz7Hh/vibSLwi/I0Apj8RanjevUrzfy xGN94mF2J9jS9dJf8mcKBrG47S9qct+OMF/30+aZk9NNIy7mMEjw6b5ELRPJu98zTkD2 +e7q1Y3GSbaH53Bw08W4+eE4tP2YF4qslNYIM8Vj2AGmSn6dDAqEIST65krHCiNL8PtQ wz9A== X-Gm-Message-State: AOUpUlEo/2WLChTf6j27ixuAZNA7buxNPf/5QtsofiZwmJ3LELjxBiKF jJ5Xs3UduxqDt3PDtcyUmKGprj1n8da7n1J8xZc= X-Google-Smtp-Source: AAOMgpeyZUPFWYgltPLDrg20D+HAG1qoEWg6HTzKkfr5ko3x8YLNw3jqo5aqePuJ82pD8OJVoJXDYegZhHNciADZD7k= X-Received: by 2002:aca:3ad4:: with SMTP id h203-v6mr19512493oia.294.1533669147814; Tue, 07 Aug 2018 12:12:27 -0700 (PDT) MIME-Version: 1.0 References: <74D8A39837DF1E4DA445A8C0B3885C503AC75235@shsmsx102.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BD4FFA1@SHSMSX104.ccr.corp.intel.com> <17C6FC15-6D2E-41A6-8996-15E665C4D28F@apple.com> <40832a91-0eca-3b9f-f533-f98666295a25@redhat.com> <5aaec7be-37e0-39cf-8961-af7b20d14c51@redhat.com> In-Reply-To: <5aaec7be-37e0-39cf-8961-af7b20d14c51@redhat.com> From: Rafael Machado Date: Tue, 7 Aug 2018 16:12:16 -0300 Message-ID: To: Laszlo Ersek Cc: Andrew Fish , "Ni, Ruiyu" , "edk2-devel@lists.01.org" , "Yao, Jiewen" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 Subject: Re: Question about memory map entries X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 19:12:29 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone Based on the information shared by the members, the understanding is that the current state of the system may impact fuutre boots. The problem is that in my case, due to specific requirements, before booting we need to stress the system's memory, allocating a big amount of memory and doing some memory validation algorithms. So the high number of allocations and frees is by choice and not by mistakes. Considering this. Is there any way to bypass the MemoryTypeInformation var store actions? Thanks and Regards Rafael Em qui, 2 de ago de 2018 =C3=A0s 17:39, Laszlo Ersek escreveu: > On 08/02/18 21:18, Rafael Machado wrote: > > Just found something interesting. > > Based on the logs from the serial port. > > > > This system works fine: > > > > "PeiInstallPeiMemory MemoryBegin 0x93D50000, MemoryLength 0xA2B0000 > > Temp Stack : BaseAddress=3D0x400000 Length=3D0x80000 > > Temp Heap : BaseAddress=3D0x480000 Length=3D0x80000 > > Total temporary memory: 1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=3D0x93D50000 Length=3D0x80000 > > Heap Offset =3D 0x93950000 Stack Offset =3D 0x93950000 > > Loading PEIM at 0x0009DFF4000 EntryPoint=3D0x0009DFF4260 PeiCore.efi" > > ... > > "CoreInitializeMemoryServices: > > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - > > 0x5AC0000" > > > > This one is bricked: > > > > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 > > Temp Stack : BaseAddress=3D0x400000 Length=3D0x80000 > > Temp Heap : BaseAddress=3D0x480000 Length=3D0x80000 > > Total temporary memory: 1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=3D0x9C9000 Length=3D0x80000 > > Heap Offset =3D 0x5C9000 Stack Offset =3D 0x5C9000 > > Loading PEIM at 0x0009DFF4000 EntryPoint=3D0x0009DFF4260 PeiCore.efi" > > ... > > "CoreInitializeMemoryServices: > > BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 > > " > > ... > > "ASSERT_EFI_ERROR (Status =3D Out of Resources) > > ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299): > > !EFI_ERROR (Status) > > AllocatePoolPages: failed to allocate 1 pages > > AllocatePool: failed to allocate 120 bytes" > > The location and the size of the permanent PEI RAM are extremely > different between the two cases. > > - Functional system: > > PeiInstallPeiMemory MemoryBegin 0x93D50000, MemoryLength 0xA2B0000 > > Base address is ~2365 MB, size is ~162 MB > > - Unbootable system: > > PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 > > Base address is ~9 MB, size is ~2518 MB > > The numbers in the second (unbootable) case look very unusual to me. The > permanent PEI RAM is usually tens or (maybe) hundreds of megabytes in > size, and tends to start much higher (usually as high as possible under > 4GB, on x86 anyway). > > > Consult the following sections in the PI spec (v1.6), volume 3: > > - 4.3 Example HOB Producer Phase Memory Map and Usage > - 5.3 PHIT HOB > > The CoreInitializeMemoryServices() function searches the HOB list for a > tested system memory "Resource Descriptor HOB that contains PHIT range > EfiFreeMemoryBottom..EfiFreeMemoryTop". (Quoted a comment from the code.) > > Basically, the function locates the system RAM HOB that contains the > free permanent PEI RAM. > > If the search fails, then we trip an ASSERT(). This does not happen in > your case, the search succeeds. > > If the search succeeds, then the DXE core will try to initialize itself > in one of three locations in the RAM area defined by that HOB. In > descending preference order: above the permanent PEI RAM, within the > free permanent PEI RAM, and below the permanent PEI RAM. > > There is also a fallback (a fourth option) when even the third one from > before proves too small -- the function will then search again for a > memory descriptor HOB, top-down, avoiding the one HOB that it found > earlier to contain the permanent PEI RAM (because, all three options for > that have already failed, see above). > > As the result of this search, your broken system finishes with: > > BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 > > "MinimalMemorySizeNeeded" includes the previous measurements from > MemoryTypeInformation, and the concrete value is very strange -- it > seems to imply that you need ~2446 MB for initializing the DXE core. > It's not surprising that the function cannot fit that anywhere, in > either of the four options described above. > > If your system has more (high) RAM to spare, try to install a resource > descriptor HOB for it. Then the fourth option might succeed. > > Honestly though, those permanent PEI RAM values (base address at ~9 MB, > size ~2518 MB) look super fishy to me in the first place. Something must > be wrong in the PEI phase with the calculation of those parameters. > Possibly, the memory resource descriptor HOBs could be wrong too. > > > ... Considering commit 3a05b13106d1 ("MdeModulePkg DxeCore: Take the > range in resource HOB for PHIT as higher priority", 2015-09-18), it write= s, > > "Also let the minimal memory size needed include the total memory bin > size needed to make sure memory bin could be allocated successfully." > > This is the reason "MinimalMemorySizeNeeded" includes > MemoryTypeInformation. Normally, MemoryTypeInformation tracks long-term > maximums that are necessary for booting an OS without memory map > fragmentation (including S4 resume). However, if you have a UEFI > application that allocates huge amounts of memory, and then *doesn't* > boot an OS, then it could invalidate MemoryTypeInformation. Because, the > maximums that MemoryTypeInformation represents, no longer reflect > requirements for booting an OS. In that case, the > "MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for > initializing the DXE core, could be invalid too. > > Thanks > Laszlo >