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

[Julien Grall <julien.grall@arm.com>]

Hi Jan,

On 27/09/2016 01:06, Jan Beulich wrote:
>>>> On 26.09.16 at 22:01, <julien.grall@arm.com> wrote:
>> On 25/09/2016 23:53, Jan Beulich wrote:
>>>>>> On 24.09.16 at 01:35, <julien.grall@arm.com> 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 happy to see a such patch for ARM.

>
>> 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).

Unifying the behavior between x86 and ARM would be the best.

Regards,

-- 
Julien Grall

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