[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Thu, 2014-07-03 at 11:12 +0100, 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.

yes, but that is what the protocol requires you to do, or to handle
realigning yourself early.

> >> FWIW, this is already the case for DOM0.
> > 
> > On that basis I'm more inclined to change dom0 to use 32kb alignment.
> It's not really 32kb alignment but an address in 0xXXXX8000.

I meant 32kb alignment.

>  If the
> kernel doesn't want to do relocation (because it's a pain to write in
> assembly code), it has to compile the kernel with a 0x8000 offset (see
> mini-os patch series).

Yes, if a kernel doesn't want to do relocaiton then it must give an

Conversely if a kernel does do relocation then it must do it properly,
not assuming 2MB alignment.

> This solution, make the kernel more tight to Xen changes. I would prefer
> if we relax this change allowing easier support of new kernel to 2MB
> alignment.

Easier isn't relevant here. The protocol requires you to deal with this
if you claim to be relocatable.
> Regards,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.