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