summaryrefslogtreecommitdiff
path: root/kexec/arch/s390/kexec-image.c
AgeCommit message (Collapse)Author
2015-11-09kexec/s390x: use mmap instead of read for slurp_file()Michael Holzheu
The slurp_fd() function allocates memory and uses the read() system call. This results in double memory consumption for image and initrd: 1) Memory allocated in user space by the kexec tool 2) Memory allocated in kernel by the kexec() system call The following illustrates the use case that we have on s390x: 1) Boot a 4 GB Linux system 2) Copy kernel and 1,5 GB ramdisk from external source into tmpfs (ram) 3) Use kexec to boot kernel with ramdisk Therefore for kexec runtime we need: 1,5 GB (tmpfs) + 1,5 GB (kexec malloc) + 1,5 GB (kernel memory) = 4,5 GB This patch introduces slurp_file_mmap() which for "normal" files uses mmap() instead of malloc()/read(). This reduces the runtime memory consumption of the kexec tool as follows: 1,5 GB (tmpfs) + 1,5 GB (kernel memory) = 3 GB Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Reviewed-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-10-03kexec: Remove unused -? option handlingGeoff Levand
The main kexec option code handles the -? option. Remove all the duplicate -? handlers in the arch code which are never used. Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro Signed-off-by: Simon Horman <horms@verge.net.au>
2013-05-26kexec/s390: cleanup: Remove non-existent header file includeZhang Yanfei
There is no elf.h in this directory, so remove the useless include. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: s390: remove ALIGN_UP and use _ALIGN_UPZhang Yanfei
We have _ALIGN_UP now, so remove ALIGN_UP and use _ALIGN_UP instead of it. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2011-09-17kexec-tools: s390: Find correct address for ramdiskMichael Holzheu
When the kernel image size is larger than 8 MiB on s390, we currently can't load the ramdisk, because it is loaded to the fix address 8 MiB (RAMDISK_ORIGIN_ADDR) per default. With this patch the ramdisk is loaded behind the image with an 1 MiB alignment. To be compatible with older kernels we still load the ramdisk to 8 MiB, if the kernel is smaller than 8 MiB. Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2011-09-07kexec-tools: Add --append option for s390Michael Holzheu
Hello Simon, From: Michael Holzheu <holzheu@linux.vnet.ibm.com> All architectures define the "--append" option together with the "--command-line" option to specify kernel parameters. This option is also used by kdump init scripts. In order to be compatible this patch introduces the "--append" option also for s390. In addition to that the help text is adjusted so that it is now the same as on all other architectures. Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2011-08-20kexec-tools: Add s390 kdump supportMichael Holzheu
This patch adds kdump support for s390 to the kexec tool and enables the "--load-panic" option. When loading the kdump kernel and ramdisk we add the address of the crashkernel memory to the normal load address. Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2010-05-19kexec-tools: Fix option/argument parsingMatt Evans
The argument parsing is currently a bit broken as main()'s getopt_long() knows nothing about either the architecture-specific options or, even more specifically, the architecture-and-loader-specific options. This patch introduces new #defines for all architectures, KEXEC_ALL_OPTIONS and KEXEC_ALL_OPT_STR. These contain all possible options for a given build, and the getopt_long() passes in main() and arch_process_options() will now recognise arch- and loader-specific options; these will not be re-ordered in argv[], there is no confusion over which argv[] entry is the kernel filename, and using '--opt=foo' and '--opt foo' both work. All architectures have command line options (and #define OPT_BLAHs) consolidated into their include/arch/option.h files. x86_64 builds parts of i386/ as well, so now both share a single option.h file (with a symlink). Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2010-02-02Mark unused parametersSimon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2006-07-27add s390 support to kexec-tools-1.101Heiko Carstens
--===============39718348520004598== Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Milton, first of all thanks for looking at the patches. > 1) When patching the command line, you read the string from the > optarg. While you clear the area in the kernel looking at > COMMAND_LINE_SIZE, you do not limit the length that you copy into > the kernel by this amount. This would seem like a buffer-overflow > situation that could easily be trapped. Yes, you're right. The kernel image could be damaged. Fixed. > 2) I noticed your ramdisk code is quite similar in function to > slurp_file in kexec/kexec.c. I realize this is probably a new > function. Fixed as well :) > 3) Your elf-rel loading seem to not be implemented, but your probe > returns 0 just like the image loader. I think you're talking about the function machine_verify_elf_rel(). Unlike the probe functions this one should return 0 on error, shouldn't it? > 4) You seem to have several addresses hard-coded into the kexec-s390.h > file. This would seem to limit the image you are loading, including > any panic crash kernel options using the current scheme. I don't > know your abi to know what other issues you might have with a more > generic kexec to image interface. (It appears you setup your image > to load as if it were from 0 but skipping IMAGE_READ_OFFSET bytes. The hard coded addresses are part of the kernel abi. Nothing needs to be changed here. Skipping the first 64k of the kernel image is ok too, since you usually would only find a loader routine there which would load the rest of the kernel image into ram and then start it. If you are really interested you might have a look at arch/s390/kernel/head.S in the kernel sources :) Also we do not plan to use the kdump feature. It doesn't make too much sense for the s390 architecture since we have already other mechanisms which allow to reliably dump complete memory and register contents at any given state of the system. The patch below should be better (still against 1.101). Guess I will come up with an improved kernel patch too. Thanks, Heiko diffstat: configure | 5 - kexec/arch/s390/Makefile | 6 + kexec/arch/s390/include/arch/options.h | 11 ++ kexec/arch/s390/kexec-elf-rel-s390.c | 23 +++++ kexec/arch/s390/kexec-image.c | 137 +++++++++++++++++++++++++++++++++ kexec/arch/s390/kexec-s390.c | 104 +++++++++++++++++++++++++ kexec/arch/s390/kexec-s390.h | 25 ++++++ kexec/kexec-syscall.h | 7 + purgatory/arch/s390/Makefile | 7 + purgatory/arch/s390/include/limits.h | 54 +++++++++++++ purgatory/arch/s390/include/stdint.h | 24 +++++ 11 files changed, 402 insertions(+), 1 deletion(-)