[PATCH v2 3/3] lmb: consider EFI memory map

[Mark Kettenis]

> Date: Wed, 11 Jan 2023 17:59:27 +0100
> From: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
> 
> On 1/11/23 17:48, Simon Glass wrote:
> > Hi,
> > 
> > On Wed, 11 Jan 2023 at 06:59, Tom Rini <trini at konsulko.com> wrote:
> >>
> >> On Wed, Jan 11, 2023 at 08:43:37AM +0100, Heinrich Schuchardt wrote:
> >>>
> >>>
> >>> On 1/11/23 01:15, Simon Glass wrote:
> >>>> Hi Heinrich,
> >>>>
> >>>> On Mon, 9 Jan 2023 at 13:53, Heinrich Schuchardt
> >>>> <heinrich.schuchardt at canonical.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 1/9/23 21:31, Simon Glass wrote:
> >>>>>> Hi Mark,
> >>>>>>
> >>>>>> On Mon, 9 Jan 2023 at 13:20, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> >>>>>>>
> >>>>>>>> From: Simon Glass <sjg at chromium.org>
> >>>>>>>> Date: Mon, 9 Jan 2023 13:11:01 -0700
> >>>>>>>>
> >>>>>>>> Hi Heinrich,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> We need to fix how EFI does addresses. It seems to use them as
> >>>>>>>> pointers but store them as u64 ?
> >>>>>
> >>>>> That is similar to what you have been doing with physical addresses.
> >>>>>
> >>>>>>>
> >>>>>>> They're defined to a 64-bit unsigned integer by the UEFI
> >>>>>>> specification, so you can't change it.
> >>>>>>
> >>>>>> I don't mean changing the spec, just changing the internal U-Boot
> >>>>>> implementation, which is very confusing. This confusion is spreading
> >>>>>> out, too.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Simon
> >>>>>
> >>>>> The real interesting thing is how memory should be managed in U-Boot:
> >>>>>
> >>>>> I would prefer to create a shared global memory management on 4KiB page
> >>>>> level used both for EFI and the rest of U-Boot.
> >>>>
> >>>> Sounds good.
> >>>>
> >>>>>
> >>>>> What EFI adds to the requirements is that you need more than free
> >>>>> (EfiConventionalMemory) and used memory. EFI knows 16 different types of
> >>>>> memory usage (see enum efi_memory_type).
> >>>>
> >>>> That's a shame. How much of this is legacy and how much is useful?
> >>>>
> >>>>>
> >>>>> When loading a file (e.g. with the "load" command) this should lead to a
> >>>>> memory reservation. You should not be able to load a second file into an
> >>>>> overlapping memory area without releasing the allocated memory first.
> >>>>>
> >>>>> This would replace lmb which currently tries to recalculate available
> >>>>> memory ab initio again and again.
> >>>>>
> >>>>> With managed memory we should be able to get rid of all those constants
> >>>>> like $loadaddr, $fdt_addr_r, $kernel_addr_r, etc. and instead use a
> >>>>> register of named loaded files.
> >>>>
> >>>> This is where standard boot comes in, since it knows what it has
> >>>> loaded and has pointers to it.
> >>>>
> >>>> I see a future where we don't use these commands when we want to save
> >>>> space. It can save 300KB from the U-Boot size.
> >>>>
> >>>> But this really has to come later, since there is so much churn already!
> >>>>
> >>>> For now, please don't add EFI allocation into lmb..that is just odd.
> >>>
> >>> It is not odd but necessary. Without it the Odroid C2 does not boot but
> >>> crashes.
> >>
> >> It's not Odroid C2, it's anything that with the bad luck to relocate
> >> over the unprotected EFI structures.
> > 
> > So can EFI use the lmb calls to reserve its memory? This patch is backwards.
> 
> Simon, the EFI code can manage memory, LMB cannot.
> 
> Every time something in U-Boot invokes LMB it recalculates reservations 
> *ab initio*.
> 
> You could use lib/efi_loader/efi_memory to replace LMB but not the other 
> way round.
> 
> We should discard LMB and replace it by proper memory management.

Actually LMB is fine.  It is the way it is used in U-Boot, where
subsystems each have their own struct lmb that is the problem.

Also note that I'm using LMB in a upcoming patch for the Apple DART
IOMMU to manage device virtual addresses.  In that case having a a
separate struct lmb actually makes sense since the device virtual
address spaces are completely separate from eachother and from the
physical address space.  So don't remove it just yet ;).