[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 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |