public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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


  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