[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

On 23/09/16 11:50, Daniel Kiper wrote:
Hi Julien,

Hi Daniel,

On Thu, Sep 22, 2016 at 06:07:26PM +0100, Julien Grall wrote:


#ifndef CONFIG_ARM
/* Whole x86 ebmalloc stuff. */
void __init free_ebmalloc_unused_mem(void)

and then call free_ebmalloc_unused_mem() from e.g.
xen/arch/arm/setup.c:init_done(). Am I right?

Bear in mind that the EFI loader on ARM is standalone. It cannot
interact with Xen.

The main goal of the EFI stub is to load the different images on the
memory and then will jump at the same starting point as when Xen is
loaded without EFI. So anything in bss will be zeroed.

AIUI, on ARM EFI we have following call sequence:
  - efi_start(),
  - efi_xen_start(),
  - real_start()
  - ...
  - el2() which zeroes BSS... ;-(((

We had the same situation on x86. So, we moved BSS init just before
efi_start() call and disabled later zero BSS if we are booted via EFI.
Could we do the same on ARM? As I can see Jan wish to use ebmalloc on
ARM too. Does it make sense for you?

The EFI on ARM has been designed to be standalone and disable page tables, flush the cache before hand and then jump in the startup beginning of the binary (as it would be done without EFI).

The problem I can see here, is ebmalloc_mem is allocated in bss rather than in init. I understand this is an optimization, to shrink down the size of the binary.

But, I am not in favor to start differing in startup code if we have EFI enabled just for that.

IHMO, anything related to the stub should be in the init section and therefore will be freed when Xen has finished to boot.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.