Re: (overlapping) lmb allocations during boot

[Michael Walle <michael@walle.cc>]

Am 2021-10-31 18:36, schrieb Mark Kettenis:
>> Date: Sun, 31 Oct 2021 16:19:56 +0100
>> From: Michael Walle <michael@walle.cc>
..

>> >> > Unless CONFIG_EFI_LOADER is defined.  Then it relocates the spin table
>> >> > to memory allocated using efi_allocate_pages().  But that function
>> >> > only looks at the EFI memory map to figure out what memory is
>> >> > available.  So I suspect that it might hand out the same memory as
>> >> > lmb_alloc().  It all looks a bit broken to me...
>> >>
>> >> Yes, that is actually my code ;) The kontron_sl28 is the only
>> >> board which uses spin tables as far as I know. It doesn't support
>> >> PSCI; at least if you don't load a bl31 TF-A. Therefore, for SMP
>> >> it uses spin tables. The relocation code work arounds a problem
>> >> with the reserved EFI code, see [1].
>> >>
>> >> And yes, it actually is broken. But so might be every code which
>> >> is using the efi_allocate_pages(), no? LMB isn't global, but is
>> >> just initialized at different places. Like before a linux kernel
>> >> is booted or when you load a file (?). And everytime the whole
>> >> memory is added, and then different regions are carved out (see
>> >> above).
>> >
>> > Right.  So it mostly works because U-Boot either ends up using a code
>> > path where it uses LMB or a path where it ends up using the EFI memory
>> > map, but never both.  Except if it hits your layerscape code.
>> >
>> > I think the right way to solve this is to allocate the memory for the
>> > spin table through some other means and use efi_add_memory_map() to
>> > reserve that memory like what is done in board/raspberrypi/rpi/rpi.c.
>> 
>> Mh. I don't think this will work, just because lmb is quite stupid
>> and has just the three steps to carve out memory:
>>   (1) arch_lmb_reserve()
>>   (2) board_lmb_reserve()
>>   (3) boot_fdt_add_mem_rsv_regions()
>> 
>> (1) will carve out u-boot code and data (2) is usually not used and
>> (3) doesn't really work IMHO, because the reserved regions are added
>> much later in the bootm flow.
>> 
>> So what would "other means" be? I could allocate the memory somehow,
>> but how can I communicate that to lmb, so it would be excluded there.
> 
> It could be a simple:
> 
>   memalign(PAGE_SIZE, PAGE_SIZE);
> 
> This would allocate memory from the heap which should be excluded from
> what lmb hands out.

Thanks, that was easy ;) Turns out the heap is between the stack and the
uboot code which is reserved by lmb (arch_lmb_reserve()).

-michael