Hi Jan,
On 25/09/2016 23:53, Jan Beulich wrote:
On 24.09.16 at 01:35, <julien.gr...@arm.com> 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@lists.xen.org
https://lists.xen.org/xen-devel
