[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 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.

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. 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).

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


Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

Xen-devel mailing list



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