On 29 January 2015 at 02:27, Scot Doyle <lkml14 at scotdoyle.com> wrote: > On Wed, 28 Jan 2015, Vivek Goyal wrote: >> On Wed, Jan 28, 2015 at 10:10:59PM +0000, Scot Doyle wrote: >> > On Wed, 28 Jan 2015, Vivek Goyal wrote: >> > > On Wed, Jan 28, 2015 at 09:14:03PM +0000, Scot Doyle wrote: >> > > > When I tested, kexec_file_load required CONFIG_RELOCATABLE. Is the same >> > > > true for kexec_load? Would it make sense to note this in the man pages >> > > > along with the need for CONFIG_KEXEC_FILE, etc? Or as an error message? >> > > >> > > Hmm.., I can't see an explicity dependency between RELOCATABLE and >> > > KEXEC. Both KEXEC and KEXEC_FILE should be able to load a kernel >> > > even if it had RELOCATABLE=n. >> > > >> > > Just that kernel will run from the address it has been built for. >> > > >> > > Thanks >> > > Vivek >> > >> > Confusing, right? kexec_file_load returns -ENOEXEC and dmesg says >> > "kexec-bzImage64: XLF_CAN_BE_LOADED_ABOVE_4G is not set." which leads to >> > arch/x86/boot/header.S line 396: >> > >> > #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64) >> > /* kernel/boot_param/ramdisk could be loaded above 4g */ >> > # define XLF1 XLF_CAN_BE_LOADED_ABOVE_4G >> > #else >> > # define XLF1 0 >> > #endif >> >> Ah, this one. Actually generic kexec file loading implementation does not >> impose this restriction. It is the image specific loader part which >> decides what kind of bzImage it can load. >> >> Current implementation (kexec-bzimage64.c), is only supporting loading >> bzImages which are 64bit and can be loaded above 4G. This simplifies >> the implementation of loader. >> >> But there is nothing which prevents one from implementing other image >> loaders. >> >> So instead of saying that kexec_file_load() depends on CONFIG_RELOCATABLE, >> it might be better to say in man page that currently this system call >> supports only loading a bzImage which is 64bit and which can be loaded >> above 4G too. >> >> Thanks >> Vivek > > Thanks, I agree, and think it would make sense to list them as part of the > page's ENOEXEC error. Scott, could you then phras a couple of sentences that capture thge details, so I can add it to the ENOEXEC error? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
