From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] libxc: arm: Load the zImage to the rambase address + 2MB Date: Thu, 03 Jul 2014 13:21:28 +0100 Message-ID: <53B54AC8.8050209@linaro.org> References: <1404137113-25101-1-git-send-email-julien.grall@linaro.org> <1404381702.14865.35.camel@kazak.uk.xensource.com> <53B52C82.500@linaro.org> <53B532E3.703@gmail.com> <1404386328.17859.5.camel@kazak.uk.xensource.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 1X2g17-0005Pl-Fo for xen-devel@lists.xenproject.org; Thu, 03 Jul 2014 12:21:33 +0000 Received: by mail-wg0-f52.google.com with SMTP id b13so139857wgh.23 for ; Thu, 03 Jul 2014 05:21:32 -0700 (PDT) In-Reply-To: <1404386328.17859.5.camel@kazak.uk.xensource.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 , Thomas Leonard Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org On 07/03/2014 12:18 PM, Ian Campbell wrote: > On Thu, 2014-07-03 at 11:39 +0100, Thomas Leonard wrote: >> On 03/07/14 11:12, Julien Grall wrote: >>> On 07/03/2014 11:01 AM, Ian Campbell wrote: >>>> On Mon, 2014-06-30 at 15:05 +0100, Julien Grall wrote: >>>>> Currently libxc is loading the kernel zImage at rambase + 32KB (0x8000). >>>>> >>>>> Kernel are usually using 1MB (or 2MB) mapping for the early page table. If >>>>> the kernel doesn't relocate itself this would require to virtual address >>>>> starting at 0xXXXX8000. This is not part of the zImage protocol, but a >>>>> convenience for Linux after the decompressor stage. Linux is able to >>>>> load at any address in the memory and it will relocate itself to respect >>>>> it own constraint. >>>> >>>> Yes, because the boot protocol does not guarantee 2MB alignment, so if >>>> the OS wants to rely on that then it is obliged to take care of >>>> relocating itself. >>>> >>>>> Load the zImage at rambase address + 2MB to make life easier for other >>>>> kernel (such as FreeBSD, Mini-OS). >>>> >>>> Whether or not it is easier these OSes *must* be prepared to be loaded >>>> at any 4k aligned address. It sounds to me like you are hoping that >>>> these OSes can *rely* on 2MB alignment, which is not the case. If they >>>> make that assumption then they are buggy, regardless of whether it >>>> happens to currently work with some loader or not. >>> >>> Using 4K alignment make impossible to use 1MB or 2MB mapping for early >>> page table. Which make the code (usually in assembly) even harder to >>> write or to impose relocation in the assembly code. >> >> This isn't the case for Mini-OS, at least. We already use a 1MB mapping >> with the 0x8000 offset just fine. The translation table (using 1MB >> sections) is 16K, which would fit nicely in the 0x8000 gap (although >> currently we don't use that space). >> >> Starting at 2MB would create an inconvenient 2MB of free memory just >> before the kernel, with no obvious way to tell xmalloc about it. > > As far as I know you need to cope with arbitrary 4K alignment I'm > afraid, that's all which is guaranteed. I think the zImage is also be able to cope on loading at 0xXXXXX200. There is no 4k alignment requirements :). > You can't assume that just because we use 0x8000 or 2MB offsets today it > will always be that way. That's all which is guaranteed if we are loading the kernel on a any bootloader. Even though, on u-boot you can choose your loading address (via u-boot image). That's why Xen is boot perfectly even if we have a 2MB-align address. I don't find mad to define a standard for booting on Xen saying the address will always be N MB align. For Mini-OS it will help to have a simpler code which doesn't need relocation. Regards, -- Julien Grall