Re: [Xen-devel] [PATCH RFC v7 07/14] efi: create new early memory allocator

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.16 at 22:01, <julien.grall@xxxxxxx> wrote:
> On 25/09/2016 23:53, Jan Beulich wrote:
>>>>> On 24.09.16 at 01:35, <julien.grall@xxxxxxx> wrote:
>>> On 23/09/2016 22:47, Daniel Kiper wrote:
>>>> @@ -66,6 +67,7 @@ integer_param("xenheap_megabytes", 
>>>> opt_xenheap_megabytes);
>>>>
>>>>  static __used void init_done(void)
>>>>  {
>>>> +    free_ebmalloc_unused_mem();
>>>
>>> I said no to this on the previous version. And I think Jan suggested a
>>> per-arch way to do it. So why is it here?
>>
>> No, I specifically did not. I intended this to be universal, but then I
>> wasn't really aware that on ARM the EFI loader is so much different
>> from x86's.
>>
>> Before coming to a final conclusion I'd really like to understand how
>> you would see dynamic memory allocation to work for pieces of data
>> to be communicated from EFI loader to main Xen. That'll determine
>> whether I'll have to grumblingly accept this code to be x86-specific.
> 
> In the current state, all the communication from EFI loader to main Xen 
> should be done via the device-tree or the data have to be in init 
> section (bss is zeroed when leaving the EFI stub and before entering to 
> Xen).

This late .bss zeroing is something which, as Daniel had already
suggested, could (and imo should) be avoided (just like he already
needs to do for x86 in his series).

> I am not against changing this behavior, however in the current state 
> this will not work at all. The call to the function will be misleading, 
> hence why I suggested a TODO for the time-being (for now the code is 
> only compiled on x86, anyway).

This doesn't really help make progress with the patch here. The
question isn't so much what current behavior should be, but what
sane behavior would be going forward. Again - we're needing your
input mainly to decide whether to put this allocator in common or
x86-specific code (with the goal of not having to move it later if at
all possible).

Jan


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