From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (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 75CB32228353E for ; Tue, 6 Mar 2018 00:32:09 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B17974023150; Tue, 6 Mar 2018 08:38:22 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-69.rdu2.redhat.com [10.10.120.69]) by smtp.corp.redhat.com (Postfix) with ESMTP id BCD21111E3E6; Tue, 6 Mar 2018 08:38:14 +0000 (UTC) To: "Brian J. Johnson" , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , Andrew Fish Cc: edk2-devel@lists.01.org, Peter Jones , Jiewen Yao , QEMU , Javier Martinez Canillas References: <20180223132311.26555-1-marcandre.lureau@redhat.com> <20180223132311.26555-4-marcandre.lureau@redhat.com> <91D51528-C2CA-41DF-921F-DBD5C2EC028C@apple.com> <26353964-066c-5664-1d67-6a79a3d21ac9@redhat.com> <5a8e107d-15f5-0278-9f89-5efb60de2719@hpe.com> From: Laszlo Ersek Message-ID: <44fec2ba-f0d1-4d04-daef-4a4603451262@redhat.com> Date: Tue, 6 Mar 2018 09:38:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5a8e107d-15f5-0278-9f89-5efb60de2719@hpe.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 06 Mar 2018 08:38:22 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 06 Mar 2018 08:38:22 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH 3/7] HACK: HobLib: workaround infinite loop X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 08:32:11 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 03/06/18 01:45, Brian J. Johnson wrote: > On 03/05/2018 12:22 PM, Laszlo Ersek wrote: >> PEIMs generally "execute in place" (XIP), i.e. they run from flash, not >> RAM. In this status they use "temporary RAM" (e.g. CPU caches configured >> like RAM) for stack & heap; whatever HOBs they produce are stored in >> "temp RAM" as well. Then one of the PEIMs "discovers permanent RAM" >> (basically it programs the memory controller and publishes the RAM >> ranges). In turn the PEI core "migrates" PEIMs from temporary to >> permanent RAM, including the HOB list. >> >> Before the temporary RAM migration (when still executing in place from >> flash), PEIMs cannot have writeable global variables. For example, >> dynamic PCDs are also maintained in a HOB (the PCD HOB). >> >> A PEIM normally cannot (and shouldn't) tell whether it is dispatched >> before or after permanent RAM is published. If needed, a PEIM can >> advertise that it depends on permanent RAM (for example because it needs >> a lot of heap memory) by including "gEfiPeiMemoryDiscoveredPpiGuid" in >> its DEPEX. >> >> Finally, it seems like a PEIM can also express, "I'm fine with being >> dispatched from both flash (XIP) vs. permanent RAM, just the PEI core >> tell me whichever it is". Apparently, if the PEIM is dispatched from >> flash (before permanent RAM is available), its call to >> RegisterForShadow() returns EFI_SUCCESS (and then its entry point >> function will be invoked for a 2nd time, after the temp RAM migration). >> And when a PEIM is dispatched from RAM (either for the very first time, >> or for the second time, after being dispatched from flash first), the >> same call returns EFI_ALREADY_STARTED. >> >> Honestly, I'm unsure what this is good for (both in general, and >> specifically for Tcg2Pei). Apparently, Tcg2Pei needs permanent RAM for >> doing the measurements (which makes sense); I just wonder what exactly >> it does so that it cannot simply specify >> "gEfiPeiMemoryDiscoveredPpiGuid" in its DEPEX. > > I haven't looked at this particular PEIM.  But one case where > registering for shadowing is useful is for improving performance when > running from permanent RAM, where writable global variables are > available.  For instance, when running from flash, a ReportStatusCode > PEIM may need to go through a slow process to locate an output hardware > device on every PPI call.  This may involve traversing the HOB list, > consulting other PPIs, even probing hardware addresses.  But once it's > shadowed to RAM, it can locate the device once, then cache its address > in a global.  Not to mention that the code itself is far, far faster > when run from RAM vs. flash.  (That's probably a key difference between > a real machine and a VM.) Ah, this sounds like a great example. Status code reporting is useful / important for debugging even before permanent RAM is installed, so the PEIM providing that PPI should not have a depex on gEfiPeiMemoryDiscoveredPpiGuid. However, once the permanent RAM is published, it makes sense to speed up the implementation. Thanks for this example! > Also, I've personally written a PEIM which saves a bunch of internal > state in a HOB, since that's the main writable storage when running from > flash.  That state includes pointers to other data (in flash.)  Once the > data is all shadowed to RAM, it updates the HOB to point to the data in > RAM.  That way it's a lot faster to access the data. Another good example. (I think I've been generally blind to this perf difference between flash and RAM, specifically concerning execution -- I must have been spoiled by virt, as you say :) ) > I also have other PEIMs which are constrained (via DEPEX) to run *only* > from RAM, since they have larger memory requirements than can be > satisfied from temporary cache-as-RAM.  That's certainly a valid > technique as well. Right, that's quite known to OVMF too, due to CpuMpPei being "hungry" like this. > RegisterForShadow() is a useful tool for making the most of the > restricted PEI environment.  And having it standardized like this is, as > Andrew said, a lot better than the hacks people had to use beforehand. I agree. I'm happy to have learned about this service! Thanks all, Laszlo