From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 2/5] xen: arm: Handle 4K aligned hypervisor load address. Date: Mon, 14 Jul 2014 23:33:56 +0100 Message-ID: <53C45AD4.2080007@linaro.org> References: <1405355930.31863.5.camel@kazak.uk.xensource.com> <1405355950-6461-2-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1405355950-6461-2-git-send-email-ian.campbell@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , xen-devel@lists.xen.org Cc: tim@xen.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org Hi Ian, On 14/07/14 17:39, Ian Campbell wrote: > Currently the boot page tables map Xen at XEN_VIRT_START using a 2MB section > mapping. This means that the bootloader must load Xen at a 2MB aligned address. > Unfortunately this is not the case with UEFI on the Juno platform where Xen > fails to boot. Furthermore the Linux boot protocol (which Xen claims to adhere > to) does not have this restriction, therefore this is our bug and not the > bootloader's. > > Fix this by adding third level pagetables to the boot time pagetables, allowing > us to map a Xen which is aligned only to a 4K boundary. This only affects the > boot time page tables since Xen will later relocate itself to a 2MB aligned > address. Strictly speaking the non-boot processors could make use of this and > use a section mapping, but it is simpler if all processors follow the same boot > path. OOI, did you think about the solution to copy Xen to a 2MB aligned address before setup the early page table? It would avoid to use third level page table during boot but will introduce an extra copy of Xen (only for the boot processor). FYI, it's what Linux does. -- Julien Grall