public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Udit Kumar <udit.kumar@nxp.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>,
	 "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: [PATCH] RFC Inform UEFI memory to Linux
Date: Sun, 17 Sep 2017 21:30:44 -0700	[thread overview]
Message-ID: <CAKv+Gu_f+u4J-XGtMVdZUQXktJE2ORFJH+=VN76Fne5q8-2vrQ@mail.gmail.com> (raw)
In-Reply-To: <AM6PR0402MB33340434FC288B2B6E17427591630@AM6PR0402MB3334.eurprd04.prod.outlook.com>

On 17 September 2017 at 21:07, Udit Kumar <udit.kumar@nxp.com> wrote:
> Hi Ard,
>
>> Thanks for the patch. But please consider carefully what you're doing:
>> My point is really that you can just remove lines 124 - 189 instead.
>
> We want, OS to re-use firmware volume area.  Therefore making firmware volume visible.
> You are right, removing lines  124-189 will do the same, and no need of adding splitting area with same
> attribute.
>
> Also, I am not sure, if we can remove this entirely, therefore we posted this as RFC:)
> Code comments says
>
>  // EDK2 does not have the concept of boot firmware copied into DRAM. To avoid the DXE
>  // core to overwrite this area we must mark the region with the attribute non-present
>
> On our architecture, we start boot from DRAM. And we haven't seen any overwrite
> by DXE. This work perfectly well for us.
>
> Do you think, on other platforms it may add a risk of overwrite ?
>

We wondered about that as well. As far as I can tell, a compressed FV
will be decompressed completely into a memory region that is reserved
for it before the DXE core is invoked. This means the outer,
uncompressed FV could technically be overwritten, but in practice, we
never refer back to it in a PrePi build, and we should probably not
even build the FV hob for this volume if we can avoid it.


  reply	other threads:[~2017-09-18  4:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-15 14:32 [PATCH] RFC Inform UEFI memory to Linux Meenakshi Aggarwal
2017-09-15 10:13 ` Leif Lindholm
2017-09-15 22:55   ` Ard Biesheuvel
2017-09-18  4:07     ` Udit Kumar
2017-09-18  4:30       ` Ard Biesheuvel [this message]
2017-09-19 12:32 ` [PATCH v2] PeiLib : " Meenakshi Aggarwal
2017-09-19  8:07   ` Sakar Arora
2017-09-19 10:10     ` Udit Kumar
2017-09-19 11:20       ` Sakar Arora
2017-09-19 12:46         ` Udit Kumar
2017-09-19 12:48     ` Ard Biesheuvel
2017-09-20  5:32       ` Sakar Arora
2017-09-20  6:32         ` Ard Biesheuvel
2017-09-20  8:20           ` Sakar Arora
2017-09-25  5:47             ` Meenakshi Aggarwal
2017-11-30 10:07             ` Udit Kumar
2017-11-30 14:33               ` Ard Biesheuvel
2017-09-20 14:59   ` Gao, Liming
2017-09-21  5:59     ` Udit Kumar

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='CAKv+Gu_f+u4J-XGtMVdZUQXktJE2ORFJH+=VN76Fne5q8-2vrQ@mail.gmail.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