[PATCH v4 4/5] efi: Reserve some memory for initial use

[Simon Glass]

Hi Tom,

On Mon, 14 Oct 2024 at 15:55, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Oct 14, 2024 at 03:50:51PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 14 Oct 2024 at 15:42, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Mon, Oct 14, 2024 at 02:19:56PM -0600, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Fri, 11 Oct 2024 at 23:47, Ilias Apalodimas
> > > > <ilias.apalodimas at linaro.org> wrote:
> > > > >
> > > > > Hi Tom
> > > > >
> > > > > On Sat, 12 Oct 2024 at 04:27, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Sat, Oct 12, 2024 at 12:01:54AM +0200, Heinrich Schuchardt wrote:
> > > > > > >
> > > > > > >
> > > > > > > Am 11. Oktober 2024 23:21:25 MESZ schrieb Simon Glass <sjg at chromium.org>:
> > > > > > > >The 'point of cooperation' is where U-Boot starts allowing EFI to use
> > > > > > > >memory outside of the U-Boot region. Until that point, it is desirable
> > > > > > > >to keep more below U-Boot free for loading images.
> > > > > > > >
> > > > > > > >Reserve a small region for this purpose.
> > > > > > >
> > > > > > > Your commit message provides no clue why this should be needed.
> > > >
> > > > Yes, I hadn't realised that people didn't understand what I was
> > > > getting at. Tom asked the same question on irc.
> > > >
> > > > It allows us to separate the lmb allocations from the EFI allocations,
> > > > so we don't need to have them both in sync. We use lmb for loading
> > > > images, then EFI takes over and does what it likes, respecting the
> > > > existing lmb reservations.
> > >
> > > But, again, LMB is not for loading of images. It's for dealing with
> > > memory reservations of various types.
> >
> > Up until recently, I believe, my statement was true, but in any case,
> > this isn't gemaine to the issue here.
> >
> > The point is, this is a useful distinction, allowing us to avoid the
> > complexity of keeping them in sync, and avoid putting this pain on
> > people who are not using EFI. We are either in U-Boot code, in which
> > case lmb rules, or we are going into an app, in which case EFI rules
> > (but must read in the lmb info).
> >
> > We are going to end up with people turning off EFI_LOADER because it
> > behaves so badly.
>
> Frankly, in hind sight I should not have agreed to split the LMB rework
> between "everything else" and "EFI" in hopes that we would then be able
> to get the "EFI" part of this agreed upon. It's "behaving badly" right
> now because we merged half of the changes in the hopes that we could get
> your agreement on the rest of them fairly quickly. This is not
> happening, however.

Well, another option would be to revert the problem patch (or two) and
do this work with careful consideration of the impacts, taking account
of my architectural objections. My main concern is using U-Boot's
memory like a stack. Suddenly this is 'OK' and we apparently want to
update U-Boot's docs to say so. It is just not a good idea!

A good part of the reason that U-Boot solves the problems it does is
that it mostly has a good design. The EFI_LOADER can be improved and
it does not need to implement things in a particular way...it just
needs to follow the spec. We are being far too rigid in saying that
every memory allocation at every stage has to be handled the same way,
etc.

That said, I did not expect the first series to cause problems. If my
EFI-test series had landed then we could perhaps have added a test for
this case of the app requesting a chunk of memory. My hope is for that
test to grow and cover some of these areas, I hope this lmb/efi thing
doesn't cause further problems and I will be looking to ensure that
this code does not affect non-EFI booting negatively.

My series to solve this same problem (EFI's use of memory) have never
been more than a few small patches. Please take a look at the current
series[1], particularly patch 5.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=427729