On 04/07/11 21:52, Sebastian Andrzej Siewior wrote: > * McClintock Matthew-B29882 | 2011-04-07 15:19:12 [+0000]: > >> On Thu, Apr 7, 2011 at 6:08 AM, Suzuki Poulose<suzuki at in.ibm.com> wrote: >>> How is this case taken care of ? Is it via the temporary mapping ? What is >>> the virtual >>> address used by temporary mapping for the "relocate_new_kernel()" ? > > It is the same as the physical :) It is hard to tell where exactly the > kernel image will be. It is somewhere between 0 and > KEXEC_CONTROL_MEMORY_LIMIT. It is allocated in > kimage_alloc_normal_control_pages(). It should not matter where it is. I guess I got my answer :). The virtual address of the relocate_new_kernel() is a kernel space VA, and hence would be above 2G (> PAGE_OFFSET), so there won't be a clash of the 1:1 mapping that we create. Also, the src/destination pages won't overlap the with the relocate_new_kernel. Hence we are safe. > >> When you load the new kexec image with kexec -l, I believe we make >> sure we are in the first 2gb of memory. Then when you kexec, all the >> TLB's are torn down and we setup a 1:1 virtual:physical mapping for >> the first 2GB of memory. Then some assembly copies kernel from the >> stored location to the destination and we boot the new kernel. > > arch/powerpc/include/asm/kexec.h: > |#ifdef CONFIG_FSL_BOOKE > | > |/* > | * On FSL-BookE we setup a 1:1 mapping which covers the first 2GiB of memory > | * and therefore we can only deal with memory within this range > | */ > |#define KEXEC_SOURCE_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1) > |#define KEXEC_DESTINATION_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1) > |#define KEXEC_CONTROL_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1) > | > |#else > > So the kernel never gives memory above 2GiB to userland. Right. If the page allocated is above 2GiB Physical Address, it is discarded, and we look for new page. Thanks Suzuki
