Re: [PATCH v2 19/23] x86/efi: create new early memory allocator

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

>>> On 20.07.15 at 16:29, <daniel.kiper@oracle.com> wrote:
> There is a problem with place_string() which is used as early memory
> allocator. It gets memory chunks starting from start symbol and
> going down. Sadly this does not work when Xen is loaded using multiboot2
> protocol because start lives on 1 MiB address. So, I tried to use
> mem_lower address calculated by GRUB2. However, it works only on some
> machines. There are machines in the wild (e.g. Dell PowerEdge R820)
> which uses first ~640 KiB for boot services code or data... :-(((
> 
> In case of multiboot2 protocol we need that place_string() only allocate
> memory chunk for EFI memory map. However, I think that it should be fixed
> instead of making another function used just in one case. I thought about
> two solutions.
> 
> 1) We could use native EFI allocation functions (e.g. AllocatePool()
>    or AllocatePages()) to get memory chunk. However, later (somewhere
>    in __start_xen()) we must copy its contents to safe place or reserve
>    this in e820 memory map and map it in Xen virtual address space.
>    In later case we must also care about conflicts with e.g. crash
>    kernel regions which could be quite difficult.

1b) Do away with efi_arch_allocate_mmap_buffer() and use 
AllocatePages() uniformly, perhaps with a per-arch specified
memory type (by means of which you can control whether the
memory contents will remain preserved until the time you want
to look at it). That will eliminate the only place_string() you're
concerned about, with a patch with better diffstat (largely due
to the questionable arch hook gone).

Jan