From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.60; helo=ma1-aaemail-dr-lapp01.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 31CBD210D93B4 for ; Wed, 8 Aug 2018 12:14:06 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id w78J1ucH025213; Wed, 8 Aug 2018 12:14:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=29pyFkz1QlgRW1e5uFNVg5mYMWBqntEgHUS8tImOQXU=; b=on6C/iD6s5sOLn4BgtehftbRJKNQc+kd0r73VP7oJ+UxPOO0jH9U7+LDIXeZp4hTLG9R r/AiErgNTvn9Tae6xZ+3mrDwFIcQCVwVdATuMD32dycNq7/wZnZNMcDqsJcvXM6S6Qvs IYgKZHiNanBz8xAelX7LmZt7pjxp9qyRAMGroNFnsthC7IwgFluMM+rf99YYjefszg31 SK7Vb9n+jG2crN574uPM/8sO7HZ7bQQqCD+xrwTa9pmWyhGgJhax84pfT5I9wvmGrF/c g85L96Al2KwyiR0UeAJD4vZ7029bqbdKs0sQEqt2lNT9J2MlggEoyHCMe9829GGAuoiF RA== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2knat4y26v-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 08 Aug 2018 12:14:03 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PD500E1HPFDCBD0@ma1-mtap-s03.corp.apple.com>; Wed, 08 Aug 2018 12:14:02 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PD500000P7BBS00@nwk-mmpp-sz12.apple.com>; Wed, 08 Aug 2018 12:14:02 -0700 (PDT) X-Va-A: X-Va-T-CD: 7b94995cc9f7b636481b394f88e9b0f7 X-Va-E-CD: 3960c102e12701346900df67a23f3972 X-Va-R-CD: d1ffea336cad1ce020d2c7bb490c171e X-Va-CD: 0 X-Va-ID: 7b9d20ce-3b76-4b58-aea8-9b1a75ce44cf X-V-A: X-V-T-CD: 7b94995cc9f7b636481b394f88e9b0f7 X-V-E-CD: 3960c102e12701346900df67a23f3972 X-V-R-CD: d1ffea336cad1ce020d2c7bb490c171e X-V-CD: 0 X-V-ID: d6baf947-9965-4a0a-a0aa-8b16b0bbf1d3 Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PD500M00P5TGB00@nwk-mmpp-sz12.apple.com>; Wed, 08 Aug 2018 12:14:01 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-08_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from [17.114.203.222] (unknown [17.114.203.222]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PD500FZJPFDUR90@nwk-mmpp-sz12.apple.com>; Wed, 08 Aug 2018 12:14:01 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <4016A4CF-F4EF-41C9-991E-63E73D8B0057@apple.com> Date: Wed, 08 Aug 2018 12:13:56 -0700 In-reply-to: Cc: "Yao, Jiewen" , Laszlo Ersek , "Ni, Ruiyu" , "edk2-devel@lists.01.org" To: Rafael Machado 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> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-08_06:, , signatures=0 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:14:06 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Aug 8, 2018, at 10:31 AM, Rafael Machado = wrote: >=20 > Hi everyone >=20 > 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? >=20 > 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 = past? >=20 No we do that all the time to remove fragmentation from the memory map = and it does not=20 Thanks, Andrew Fish > Thanks and Regards > Rafael >=20 > Em qua, 8 de ago de 2018 =C3=A0s 08:55, Rafael Machado = > escreveu: > Hi Jiewen >=20 > Thanks for highlighting this.=20 > Just checked and we just add the Reserved/Acpi/Runtime types. >=20 > Seems the guess that this would be related to the MemoryTypeInfo var = is not the correct way to follow. >=20 > We'll keep working on it, maybe asking more questions to the community = in future. > Thank you all for the help and guidance!=20 > In case someone has any comment or idea, please feel free to share. >=20 > Rafael =20 >=20 > =20 >=20 > Em ter, 7 de ago de 2018 =C3=A0s 19:42, Yao, Jiewen = > escreveu: > Hi >=20 > It is unclear to me that which type you have put to MemoryTypeInfo = table. >=20 > =20 >=20 > By design, we only need put Reserved/Acpi/Runtime, which should be = quite small. >=20 > =20 >=20 > Do you put any other type into MemoryTypeInfo table? >=20 > =20 >=20 > Thank you >=20 > Yao Jiewen >=20 > =C2=A0 <> > <>From: Rafael Machado [mailto:rafaelrodrigues.machado@gmail.com = ]=20 > Sent: Wednesday, August 8, 2018 3:12 AM > To: Laszlo Ersek > > Cc: Andrew Fish >; Ni, Ruiyu = >; = edk2-devel@lists.01.org ; Yao, Jiewen = > >=20 >=20 > Subject: Re: [edk2] Question about memory map entries >=20 >=20 > =20 >=20 > Hi everyone >=20 > =20 >=20 > Based on the information shared by the members, the understanding is = that the current state of the system may impact fuutre boots.=20 >=20 > 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. >=20 > So the high number of allocations and frees is by choice and not by = mistakes. >=20 > =20 >=20 > Considering this. Is there any way to bypass the MemoryTypeInformation = var store actions? >=20 > =20 >=20 > Thanks and Regards >=20 > Rafael=20 >=20 > =20 >=20 > Em qui, 2 de ago de 2018 =C3=A0s 17:39, Laszlo Ersek = > escreveu: >=20 > On 08/02/18 21:18, Rafael Machado wrote: > > Just found something interesting. > > Based on the logs from the serial port. > >=20 > > This system works fine: > >=20 > > "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" > >=20 > > This one is bricked: > >=20 > > "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" >=20 > The location and the size of the permanent PEI RAM are extremely > different between the two cases. >=20 > - Functional system: >=20 > PeiInstallPeiMemory MemoryBegin 0x93D50000, MemoryLength 0xA2B0000 >=20 > Base address is ~2365 MB, size is ~162 MB >=20 > - Unbootable system: >=20 > PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 >=20 > Base address is ~9 MB, size is ~2518 MB >=20 > 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). >=20 >=20 > Consult the following sections in the PI spec (v1.6), volume 3: >=20 > - 4.3 Example HOB Producer Phase Memory Map and Usage > - 5.3 PHIT HOB >=20 > 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.) >=20 > Basically, the function locates the system RAM HOB that contains the > free permanent PEI RAM. >=20 > If the search fails, then we trip an ASSERT(). This does not happen in > your case, the search succeeds. >=20 > 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. >=20 > 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). >=20 > As the result of this search, your broken system finishes with: >=20 > BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 >=20 > "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. >=20 > If your system has more (high) RAM to spare, try to install a resource > descriptor HOB for it. Then the fourth option might succeed. >=20 > 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. >=20 >=20 > ... Considering commit 3a05b13106d1 ("MdeModulePkg DxeCore: Take the > range in resource HOB for PHIT as higher priority", 2015-09-18), it = writes, >=20 > "Also let the minimal memory size needed include the total memory bin > size needed to make sure memory bin could be allocated successfully." >=20 > 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. >=20 > Thanks > Laszlo >=20