[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH RFC v7 07/14] efi: create new early memory allocator
- To: Jan Beulich <JBeulich@xxxxxxxx>
- From: Julien Grall <julien.grall@xxxxxxx>
- Date: Tue, 27 Sep 2016 16:23:47 -0700
- Cc: Juergen Gross <JGross@xxxxxxxx>, sstabellini@xxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, Daniel Kiper <daniel.kiper@xxxxxxxxxx>, cardoe@xxxxxxxxxx, pgnet.dev@xxxxxxxxx, ning.sun@xxxxxxxxx, david.vrabel@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, qiaowei.ren@xxxxxxxxx, gang.wei@xxxxxxxxx, fu.wei@xxxxxxxxxx
- Delivery-date: Tue, 27 Sep 2016 23:24:01 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
Hi Jan,
On 27/09/2016 01:06, Jan Beulich wrote:
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 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
