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

[Mark Kettenis]

> From: Simon Glass <sjg at chromium.org>
> Date: Mon, 9 Jan 2023 13:11:01 -0700
> 
> Hi Heinrich,
> 
> On Thu, 5 Jan 2023 at 13:25, Heinrich Schuchardt
> <heinrich.schuchardt at canonical.com> wrote:
> >
> > Add reservations for all EFI memory areas that are not
> > EFI_CONVENTIONAL_MEMORY.
> >
> > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
> > ---
> > v2:
> >         use efi_get_memory_map_alloc()
> > ---
> >  lib/lmb.c | 36 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 36 insertions(+)
> >
> > diff --git a/lib/lmb.c b/lib/lmb.c
> > index c599608fa3..ec790760db 100644
> > --- a/lib/lmb.c
> > +++ b/lib/lmb.c
> > @@ -7,7 +7,9 @@
> >   */
> >
> >  #include <common.h>
> > +#include <efi_loader.h>
> >  #include <image.h>
> > +#include <mapmem.h>
> >  #include <lmb.h>
> >  #include <log.h>
> >  #include <malloc.h>
> > @@ -153,6 +155,37 @@ void arch_lmb_reserve_generic(struct lmb *lmb, ulong sp, ulong end, ulong align)
> >         }
> >  }
> >
> > +/**
> > + * efi_lmb_reserve() - add reservations for EFI memory
> > + *
> > + * Add reservations for all EFI memory areas that are not
> > + * EFI_CONVENTIONAL_MEMORY.
> > + *
> > + * @lmb:       lmb environment
> > + * Return:     0 on success, 1 on failure
> > + */
> > +static __maybe_unused int efi_lmb_reserve(struct lmb *lmb)
> > +{
> > +       struct efi_mem_desc *memmap = NULL, *map;
> > +       efi_uintn_t i, map_size = 0;
> > +       efi_status_t ret;
> > +
> > +       ret = efi_get_memory_map_alloc(&map_size, &memmap);
> > +       if (ret != EFI_SUCCESS)
> > +               return 1;
> > +
> > +       for (i = 0, map = memmap; i < map_size / sizeof(*map); ++map, ++i) {
> > +               if (map->type != EFI_CONVENTIONAL_MEMORY)
> > +                       lmb_reserve(lmb,
> > +                                   map_to_sysmem((void *)(uintptr_t)
> > +                                                 map->physical_start),
> 
> We need to fix how EFI does addresses. It seems to use them as
> pointers but store them as u64 ?

They're defined to a 64-bit unsigned integer by the UEFI
specification, so you can't change it.