From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v2 19/23] x86/efi: create new early memory allocator Date: Thu, 27 Aug 2015 05:23:47 -0600 Message-ID: <55DF0F63020000780009D625__35777.9349935756$1440674708$gmane$org@prv-mh.provo.novell.com> References: <1437402558-7313-1-git-send-email-daniel.kiper@oracle.com> <1437402558-7313-20-git-send-email-daniel.kiper@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZUvHd-00067p-Ob for xen-devel@lists.xenproject.org; Thu, 27 Aug 2015 11:23:53 +0000 In-Reply-To: <1437402558-7313-20-git-send-email-daniel.kiper@oracle.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper Cc: Juergen Gross , grub-devel@gnu.org, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, roy.franz@linaro.org, ning.sun@intel.com, david.vrabel@citrix.com, phcoder@gmail.com, xen-devel@lists.xenproject.org, qiaowei.ren@intel.com, keir@xen.org, richard.l.maliszewski@intel.com, gang.wei@intel.com, fu.wei@linaro.org List-Id: xen-devel@lists.xenproject.org >>> On 20.07.15 at 16:29, wrote: > There is a problem with place_string() which is used as early memory > allocator. It gets memory chunks starting from start symbol and > going down. Sadly this does not work when Xen is loaded using multiboot2 > protocol because start lives on 1 MiB address. So, I tried to use > mem_lower address calculated by GRUB2. However, it works only on some > machines. There are machines in the wild (e.g. Dell PowerEdge R820) > which uses first ~640 KiB for boot services code or data... :-((( > > In case of multiboot2 protocol we need that place_string() only allocate > memory chunk for EFI memory map. However, I think that it should be fixed > instead of making another function used just in one case. I thought about > two solutions. > > 1) We could use native EFI allocation functions (e.g. AllocatePool() > or AllocatePages()) to get memory chunk. However, later (somewhere > in __start_xen()) we must copy its contents to safe place or reserve > this in e820 memory map and map it in Xen virtual address space. > In later case we must also care about conflicts with e.g. crash > kernel regions which could be quite difficult. 1b) Do away with efi_arch_allocate_mmap_buffer() and use AllocatePages() uniformly, perhaps with a per-arch specified memory type (by means of which you can control whether the memory contents will remain preserved until the time you want to look at it). That will eliminate the only place_string() you're concerned about, with a patch with better diffstat (largely due to the questionable arch hook gone). Jan