From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [PATCH 17/18] x86/efi: create new early memory
	allocator
Date: Tue, 03 Mar 2015 08:04:09 +0000
Message-ID: <54F5790902000078000657AD__48147.4304608584$1425369970$gmane$org@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>
	<CAFECyb-vfyBA8v56+mf78osWEjNBcGM+DLEi3EwQx-3qdNAaCw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1YShoL-00028C-E1
	for xen-devel@lists.xenproject.org; Tue, 03 Mar 2015 08:04:13 +0000
In-Reply-To: <CAFECyb-vfyBA8v56+mf78osWEjNBcGM+DLEi3EwQx-3qdNAaCw@mail.gmail.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Roy Franz <roy.franz@linaro.org>
Cc: Juergen Gross <JGross@suse.com>, grub-devel@gnu.org, keir <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Daniel Kiper <daniel.kiper@oracle.com>, ning.sun@intel.com, david.vrabel@citrix.com, Vladimir Serbinenko <phcoder@gmail.com>, xen-devel <xen-devel@lists.xenproject.org>, qiaowei.ren@intel.com, richard.l.maliszewski@intel.com, gang.wei@intel.com, Fu Wei <fu.wei@linaro.org>
List-Id: xen-devel@lists.xenproject.org

>>> On 02.03.15 at 21:25, <roy.franz@linaro.org> wrote:
> On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>> @@ -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).
> 
> 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.

The 64k size here is to be debated anyway I think. We currently have
about 1Mb in the x86 variant, and I'd much rather see the pool be
this size initially, properly taking care of releasing to the allocator any
unused portions of it.

Jan