From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YSY3k-0003Qq-EH for mharc-grub-devel@gnu.org; Mon, 02 Mar 2015 16:39:28 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSWto-0007nd-RZ for grub-devel@gnu.org; Mon, 02 Mar 2015 15:25:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSWtk-0004k4-Mr for grub-devel@gnu.org; Mon, 02 Mar 2015 15:25:08 -0500 Received: from mail-la0-f54.google.com ([209.85.215.54]:35453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSWtk-0004ih-GA for grub-devel@gnu.org; Mon, 02 Mar 2015 15:25:04 -0500 Received: by labgm9 with SMTP id gm9so32980126lab.2 for ; Mon, 02 Mar 2015 12:25:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CSJaEmL6b8I8qqy66l+w1qW9T1qQ3Ph7JZ62Vc1ETrw=; b=L1tlzCwx55XJ1f3ZrTwdPC2LMqv1B/TgLwo8TA5FCPkijM10mTee012FndpHuV20Dn ELGKVMM+n06zAnwRJZ6UNJrwsIlpeNvsOf1gyD1K/QDkNgie1HInZEw7wnEzMOemxqTH lYOC2Ml8t3O8h4UirnaXUEs8g5U+jjcJGspi8hH1Aox1zDba6qU5O8BCXzFYV8pi2c2f hGDaCAttVYkGKdlZ5ezg4HIZSC11qM3Tb0zBwLPb1MahwOKzyEbUznXvennLoPsPAthY kFbCjTYP/ac4I40i3MQC1frxB8Q0Ecx6aJNKFzRl4/pTb6vpTdVhSpBkinFPbnNetYp2 i5Kw== X-Gm-Message-State: ALoCoQlEpk2K0u1Z5+DYZn6CJS/P7A4f8+dOPWdeZ5VRPRUjX8DxXcV/aAdqeWQZaqn3oDqPjEYB MIME-Version: 1.0 X-Received: by 10.152.2.227 with SMTP id 3mr25368777lax.85.1425327903673; Mon, 02 Mar 2015 12:25:03 -0800 (PST) Received: by 10.25.87.148 with HTTP; Mon, 2 Mar 2015 12:25:03 -0800 (PST) In-Reply-To: <54F4AAB502000078000654ED@mail.emea.novell.com> References: <1422640462-28103-1-git-send-email-daniel.kiper@oracle.com> <1422640462-28103-18-git-send-email-daniel.kiper@oracle.com> <54F4AAB502000078000654ED@mail.emea.novell.com> Date: Mon, 2 Mar 2015 12:25:03 -0800 Message-ID: Subject: Re: [PATCH 17/18] x86/efi: create new early memory allocator From: Roy Franz To: Jan Beulich Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.215.54 X-Mailman-Approved-At: Mon, 02 Mar 2015 16:39:25 -0500 Cc: Juergen Gross , grub-devel@gnu.org, keir , Ian Campbell , Stefano Stabellini , Andrew Cooper , Daniel Kiper , ning.sun@intel.com, david.vrabel@citrix.com, Vladimir Serbinenko , xen-devel , qiaowei.ren@intel.com, richard.l.maliszewski@intel.com, gang.wei@intel.com, Fu Wei X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 20:25:10 -0000 On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich wrote: >>>> On 30.01.15 at 18:54, wrote: >> --- a/xen/arch/x86/efi/efi-boot.h >> +++ b/xen/arch/x86/efi/efi-boot.h >> @@ -103,9 +103,35 @@ static void __init relocate_trampoline(unsigned long phys) >> *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4; >> } >> >> +#define __MALLOC_SIZE 65536 >> + >> +static char __malloc_mem[__MALLOC_SIZE]; >> +static char *__malloc_free = NULL; >> + >> +static void __init *__malloc(size_t size) > > Please do away with all these prefixing underscores. > >> +{ >> + void *ptr; >> + >> + /* >> + * Init __malloc_free on runtime. Static initialization >> + * will not work because it puts virtual address there. >> + */ >> + if ( __malloc_free == NULL ) >> + __malloc_free = __malloc_mem; >> + >> + ptr = __malloc_free; >> + >> + __malloc_free += size; >> + >> + if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) ) >> + blexit(L"Out of static memory\r\n"); >> + >> + return ptr; >> +} > > You're ignoring alignment requirements here altogether. > >> @@ -192,12 +218,7 @@ static void __init >> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable, >> >> static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size) >> { >> - place_string(&mbi.mem_upper, NULL); >> - mbi.mem_upper -= *map_size; >> - mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR); >> - if ( mbi.mem_upper < xen_phys_start ) >> - return NULL; >> - return (void *)(long)mbi.mem_upper; >> + return __malloc(*map_size); >> } > > Which then even suggests that _if_ we go this route, this could be > shared with ARM (and hence become common code again). > > Jan > We could do the same thing on ARM. For ARM, 2 allocations are done: 1 for the FDT, and this one for the EFI memory map. Both of these are currently allocated with EFI allocation functions, so don't have fixed size limits. If we go with the fixed size pool, I don't think that 64k will be enough for the ARM case, as FDTs can be 20-50k in size. Roy