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
