Re: [PATCH 17/18] x86/efi: create new early memory allocator

["Jan Beulich" <JBeulich@suse.com>]

>>> On 02.03.15 at 21:25, <roy.franz@linaro.org> wrote:
> On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>> @@ -192,12 +218,7 @@ static void __init
>>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>>>
>>>  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>>>  {
>>> -    place_string(&mbi.mem_upper, NULL);
>>> -    mbi.mem_upper -= *map_size;
>>> -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
>>> -    if ( mbi.mem_upper < xen_phys_start )
>>> -        return NULL;
>>> -    return (void *)(long)mbi.mem_upper;
>>> +    return __malloc(*map_size);
>>>  }
>>
>> Which then even suggests that _if_ we go this route, this could be
>> shared with ARM (and hence become common code again).
> 
> We could do the same thing on ARM.  For ARM, 2 allocations are done: 1
> for the FDT, and
> this one for the EFI memory map.  Both of these are currently
> allocated with EFI allocation
> functions, so don't have fixed size limits.  If we go with the fixed
> size pool, I don't think that 64k
> will be enough for the ARM case, as FDTs can be 20-50k in size.

The 64k size here is to be debated anyway I think. We currently have
about 1Mb in the x86 variant, and I'd much rather see the pool be
this size initially, properly taking care of releasing to the allocator any
unused portions of it.

Jan