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

[Julien Grall <julien.grall@linaro.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