Re: [Xen-devel] [PATCH] libxc: arm: Load the zImage to the rambase address + 2MB

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

You can't assume that just because we use 0x8000 or 2MB offsets today it
will always be that way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel