[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



Hi Jan,

On 25/09/2016 23:53, Jan Beulich wrote:
On 24.09.16 at 01:35, <julien.grall@xxxxxxx> wrote:
Hi Daniel,

On 23/09/2016 22:47, Daniel Kiper wrote:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 38eb888..2085f35 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -38,6 +38,7 @@
 #include <xen/vmap.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/acpi.h>
+#include <xen/efi.h>
 #include <asm/alternative.h>
 #include <asm/page.h>
 #include <asm/current.h>
@@ -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).

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

Regards,

--
Julien Grall

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

 


Rackspace

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