[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |