[PATCH v3 03/15] efi: memory: use the lmb API's for allocating and freeing memory

[Tom Rini]

On Thu, Oct 17, 2024 at 05:23:08PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> On Tue, 15 Oct 2024 at 13:05, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Tue, Oct 15, 2024 at 07:10:27AM -0600, Simon Glass wrote:
[snip]
> > > Even if efi_init_obj_list(), I don't like treating U-Boot's memory as
> > > a stack to just grow into. But as a first step, I do want to ensure
> > > that non-EFI boot can be more like U-Boot.
> >
> > I think you intended a negation somewhere in that last sentence.
> 
> It looks right to me.

I cannot understand what you mean by "I do want to ensure that non-EFI
boot can be more like U-Boot." then, sorry.

> > But among the points trying to be made here are that no, we didn't start
> > an EFI app (a previous point of contention you had), even if we used an
> > EFI feature. We may or may not use more.
> 
> Yes, we have ended up with what I feel is a dog's breakfast. I'd like
> to tidy it up.

Getting back to a point I just made elsewhere, this is further you
talking like the whole of EFI_LOADER is bad.

> >  But saying "I guess now we can
> > live with the EFI pool doing what it needs" is quite silly since we've
> > potentially done almost nothing else.
> 
> Do you mean that it is inconsistent for me to say that when
> efi_init_obj_list() is called, any memory can be used? Yes it is
> inconsistent. In fact I may as well just say that we should use
> U-Boot's region until we can't, e.g. we exhaust the reserved space. By
> that time, the boot will be well-advanced, I suspect. I'll take a look
> at some Ubuntu boots and see what happens in practice.
> 
> > And so why did we make this
> > special case anyways?
> 
> Once an EFI feature is used, we know we are booting EFI, so it might
> start using memory outside the U-Boot region. That's all.

No, we don't. As another of your threads noted, we print a warning
message about not being able to use persistent UEFI variables. At that
point we can further go and see that no, this is not a UEFI-boot capable
image and move on. But we've now crossed your point where you contend
that UEFI is unavoidable.

> > This is why I keep saying various versions of, you
> > need to re-think what you consider "U-Boot memory". If you have concerns
> > about our stack smashing in to things, that's the problem to address (it
> > could just as easily smash an initrd placed high in memory by a non-EFI
> > bootmeth).
> 
> I am not yet ready to re-think that, because my intuition tells me
> that I have this right. I would like to get some of my ideas in, to
> solve this problem. To do that, we need to be willing to let U-Boot
> allocate memory (on EFI's behalf) as it wishes, within the spec, not
> necessarily based on just what the code does today.

Well, in that I believe Heinrich has suggested some further changes to
how the EFI memory map is handled, now that the lmb refactor is in and
largely (but not entirely, Caleb made some good points on IRC Friday)
done, we'll see what comes of that. But I'm not sure who you have
convinced that we need to make these changes for a conceptual, rather
than functional problem.

All of that very much said, this is one of the times I wish I could
figure out how to introduce a technical steering committee structure of
some sort, and how to have matters voted on in some manner.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241019/cc52746e/attachment.sig>