From: Laszlo Ersek <lersek@redhat.com>
To: "Brian J. Johnson" <brian.johnson@hpe.com>,
"Marc-André Lureau" <marcandre.lureau@gmail.com>,
"Andrew Fish" <afish@apple.com>
Cc: edk2-devel@lists.01.org, Peter Jones <pjones@redhat.com>,
Jiewen Yao <jiewen.yao@intel.com>, QEMU <qemu-devel@nongnu.org>,
Javier Martinez Canillas <javierm@redhat.com>
Subject: Re: [PATCH 3/7] HACK: HobLib: workaround infinite loop
Date: Tue, 6 Mar 2018 09:38:14 +0100 [thread overview]
Message-ID: <44fec2ba-f0d1-4d04-daef-4a4603451262@redhat.com> (raw)
In-Reply-To: <5a8e107d-15f5-0278-9f89-5efb60de2719@hpe.com>
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
next prev parent reply other threads:[~2018-03-06 8:32 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-23 13:23 [PATCH 0/7] RFC: ovmf: preliminary TPM2 support marcandre.lureau
2018-02-23 13:23 ` [PATCH 1/7] SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib dependency marcandre.lureau
2018-02-23 15:58 ` Laszlo Ersek
2018-02-24 0:09 ` Yao, Jiewen
2018-03-02 14:34 ` Laszlo Ersek
2018-02-23 13:23 ` [PATCH 2/7] ovmf: link with Tcg2ConfigPei module marcandre.lureau
2018-02-23 17:31 ` Laszlo Ersek
2018-03-01 14:59 ` Marc-André Lureau
2018-03-02 10:50 ` Laszlo Ersek
2018-02-23 13:23 ` [PATCH 3/7] HACK: HobLib: workaround infinite loop marcandre.lureau
2018-02-23 19:14 ` Laszlo Ersek
2018-02-23 19:45 ` Andrew Fish
2018-03-05 14:05 ` Marc-André Lureau
2018-03-05 18:22 ` Laszlo Ersek
2018-03-05 20:18 ` Andrew Fish
2018-03-06 0:45 ` Brian J. Johnson
2018-03-06 8:38 ` Laszlo Ersek [this message]
2018-03-06 2:02 ` Gao, Liming
2018-02-23 13:23 ` [PATCH 4/7] ovmf: link with Tcg2Pei module marcandre.lureau
2018-02-26 9:38 ` Laszlo Ersek
2018-03-01 15:08 ` Marc-André Lureau
2018-03-02 10:51 ` Laszlo Ersek
2018-02-23 13:23 ` [PATCH 5/7] ovmf: link with Tcg2Dxe module marcandre.lureau
2018-02-26 9:50 ` Laszlo Ersek
2018-03-05 15:45 ` Marc-André Lureau
2018-03-05 19:25 ` Laszlo Ersek
2018-02-23 13:23 ` [PATCH 6/7] ovmf: link with Tcg2ConfigDxe module marcandre.lureau
2018-02-26 9:58 ` Laszlo Ersek
2018-03-01 16:59 ` Stefan Berger
2018-03-02 11:12 ` Laszlo Ersek
2018-03-02 13:35 ` [Qemu-devel] " Stefan Berger
2018-02-23 13:23 ` [PATCH 7/7] ovmf: add DxeTpm2MeasureBootLib marcandre.lureau
2018-02-26 10:29 ` Laszlo Ersek
2018-02-23 15:55 ` [PATCH 0/7] RFC: ovmf: preliminary TPM2 support Laszlo Ersek
2018-03-01 16:36 ` [Qemu-devel] " Stefan Berger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44fec2ba-f0d1-4d04-daef-4a4603451262@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox