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

[Julien Grall <julien.grall@xxxxxxx>]

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. */
> > > ...
> > > #else
> > > void __init free_ebmalloc_unused_mem(void)
> > > {
> > > }
> > > #endif
> > >
> > > 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.
Regards,

--
Julien Grall

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