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::235; helo=mail-oi0-x235.google.com; envelope-from=rafaelrodrigues.machado@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 4AA4821CAD998 for ; Wed, 8 Aug 2018 12:43:36 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id m11-v6so5851730oic.2 for ; Wed, 08 Aug 2018 12:43:36 -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=Xx0lYggwu4ONtRmEAFltfp6JA1Pz6C8rSlZDlGog7vc=; b=KVbU1X4+nz608hkw6xDE4BLKNjGx9JMG+4MlloMSlvlrdyPy+bxy2MwRcO5jLqIp9s K9xh+zYp62inOtNCHfJ1MNSwfjgtxtkRyYCvpMpGMcwqLy7QJiSY9dS5TN+CpPB6w0yX 8yPqKu/97uuUW79c3LBi26Y63C97FdMc7UqWSwz2KizFVdHfGsThQhMOztcp7UCLj/Cw QNSskbN6RTZ7rNWLmocrJ7YNjIROeANHqWtemwCw7rWz3zdtj+sFB2B+GaoREnxVzw5P Ddaoh0SZqguZck2vA+BxPTXGncwSNx3hyAg8+V+Y9innH6TBoXzsgcY9escoB8MiLH85 dXvA== 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=Xx0lYggwu4ONtRmEAFltfp6JA1Pz6C8rSlZDlGog7vc=; b=jVq8n8hNlQhHTR0lZGlP8yoJV2701wWqBD0FfDoubjUDG+lF9nVz4CsZjVAW3JTQ78 gVnucPJCSBYBxmmD10XMQFXK13Bq9SQKx1EMa4amzsF/XUmWnw6hcNHO4HKjKARkQTXr +hMpGvTH3TOkU7+y0z53Fn11UuqC1C8icQQtABlbRBpAfLuFr0S7+5chEzomecIZjmzd IscY8gl1fUCaljfPORA6Op+b3bJJZOPcJq/PHLTaI6NGRzk1HzYM78Ekt2qxK5/KwJwB uOv75vnDQ+5zTpW3qCx9jbbzEaFMzHw+RHLgAera58YaSHO/Vj1zD4SyJ8aXYM/hRKq2 CbIA== X-Gm-Message-State: AOUpUlEg/xRrKtGg39TpxhwCrI/508mcBkkdM2U8IQfStVLC7Cs/lQHP d9gvtIbnqx+1buBZyi6+GsbxAZpZSZZA2pSOV4j8Mb87ZE4= X-Google-Smtp-Source: AA+uWPyZtwXq4pvecq/ObcWGLdURrAFA19OzKGtaxtK4/9n0f0wdm40gIkyi26nH6LUAKE2T22XDVmLPDDKetuBgHvc= X-Received: by 2002:aca:d0cc:: with SMTP id j73-v6mr4010599oiy.255.1533757415217; Wed, 08 Aug 2018 12:43:35 -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> <74D8A39837DF1E4DA445A8C0B3885C503ACFC002@shsmsx102.ccr.corp.intel.com> <4016A4CF-F4EF-41C9-991E-63E73D8B0057@apple.com> In-Reply-To: <4016A4CF-F4EF-41C9-991E-63E73D8B0057@apple.com> From: Rafael Machado Date: Wed, 8 Aug 2018 16:43:23 -0300 Message-ID: To: Andrew Fish Cc: "Yao, Jiewen" , Laszlo Ersek , "Ni, Ruiyu" , "edk2-devel@lists.01.org" 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: Wed, 08 Aug 2018 19:43:36 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew. Thanks for the clarification! Rafael Em qua, 8 de ago de 2018 =C3=A0s 16:14, Andrew Fish escre= veu: > > On Aug 8, 2018, at 10:31 AM, Rafael Machado < > rafaelrodrigues.machado@gmail.com> wrote: > > Hi everyone > > One question that was not answered and that could help us, is about > skipping the MemoryTypeInfo variable usage. > Is there any way to do this skip at a UEFI App ? > Simple erasing the MemoryTypeInfo var seems a little to violent from our > perspective. What do you think? > > Seems the system we're having this problem has some inconsistency when > filling the MemoryTypeInfo var before exiting the previous boot, and > seems to consider the BootServices memory type also to be stored at the > var. Does anyone remember of this kind of issue on some system in the pas= t? > > > No we do that all the time to remove fragmentation from the memory map an= d > it does not > > Thanks, > > Andrew Fish > > Thanks and Regards > Rafael > > Em qua, 8 de ago de 2018 =C3=A0s 08:55, Rafael Machado < > rafaelrodrigues.machado@gmail.com> escreveu: > >> Hi Jiewen >> >> Thanks for highlighting this. >> Just checked and we just add the Reserved/Acpi/Runtime types. >> >> Seems the guess that this would be related to the MemoryTypeInfo var is >> not the correct way to follow. >> >> We'll keep working on it, maybe asking more questions to the community i= n >> future. >> Thank you all for the help and guidance! >> In case someone has any comment or idea, please feel free to share. >> >> Rafael >> >> >> >> Em ter, 7 de ago de 2018 =C3=A0s 19:42, Yao, Jiewen >> escreveu: >> >>> Hi >>> >>> It is unclear to me that which type you have put to MemoryTypeInfo tabl= e. >>> >>> >>> >>> By design, we only need put Reserved/Acpi/Runtime, which should be quit= e >>> small. >>> >>> >>> >>> Do you put any other type into MemoryTypeInfo table? >>> >>> >>> >>> Thank you >>> >>> Yao Jiewen >>> >>> >>> >>> *From:* Rafael Machado [mailto:rafaelrodrigues.machado@gmail.com] >>> *Sent:* Wednesday, August 8, 2018 3:12 AM >>> *To:* Laszlo Ersek >>> *Cc:* Andrew Fish ; Ni, Ruiyu ; >>> edk2-devel@lists.01.org; Yao, Jiewen >>> >>> >>> *Subject:* Re: [edk2] Question about memory map entries >>> >>> >>> >>> 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. Th= e >>> 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 fo= r >>> 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 mus= t >>> 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 >>> writes, >>> >>> "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, th= e >>> 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 >>> >>>