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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Tue, Mar 03, 2015 at 08:04:09AM +0000, Jan Beulich wrote:
> >>> On 02.03.15 at 21:25, <roy.franz@xxxxxxxxxx> wrote:
> > On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>>>> On 30.01.15 at 18:54, <daniel.kiper@xxxxxxxxxx> 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.

Thanks for your comments guys. I will reply for all of them probably
next week. Now I am busy with bugs in GRUB2. Please stay tuned.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel