summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-01-28multiboot-x86: pass framebuffer information when requestedFriedemann Gerold
When the kernel requests video information, pass it the framebuffer information in the multiboot header from the linux framebuffer ioctl's. With the arch specific --reset-vga or --consolve-vga options, purgatory will reset the framebuffer so pass information for standard ega text mode. Signed-off-by: Friedemann Gerold <cinap_lenrek@felloff.net> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-28multiboot-x86: pass ACPI reserved memory information in memory mapFriedemann Gerold
Use the appropriate types for ACPI reclaim and ACPI NVS ranges in the multiboot memory map. This allows the kernel to locate ACPI tables on UEFI systems without having a explicit pointer to the RSD. Signed-off-by: Friedemann Gerold <cinap_lenrek@felloff.net> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-28multiboot-x86: support for non-elf kernelsFriedemann Gerold
Add support for non-elf multiboot kernels (such as Plan 9) by handling the MULTIBOOT_AOUT_KLUDGE bit. When the bit is clear then we are dealing with an ELF file and probe for ELF as before with elf_x86_probe(). When the bit is set then load_addr, load_end_addr, header_addr and entry_addr from the multiboot header are used load the memory image. Signed-off-by: Friedemann Gerold <cinap_lenrek@felloff.net> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-15arm64: add kexec_file_load supportAKASHI Takahiro
With this patch, kexec_file_load() system call is supported. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09arm64: Add support to read PHYS_OFFSET from 'kcore' - pt_note or pt_load (if ↵Bhupesh Sharma
available) On certain arm64 platforms, it has been noticed that due to a hole at the start of physical ram exposed to kernel (i.e. it doesn't start from address 0), the kernel still calculates the 'memstart_addr' kernel variable as 0. Whereas the SYSTEM_RAM or IOMEM_RESERVED range in '/proc/iomem' would carry a first entry whose start address is non-zero (as the physical ram exposed to the kernel starts from a non-zero address). In such cases, if we rely on '/proc/iomem' entries to calculate the phys_offset, then we will have mismatch between the user-space and kernel space 'PHYS_OFFSET' value. The present 'kexec-tools' code does the same in 'get_memory_ranges_iomem_cb()' function when it makes a call to 'set_phys_offset()'. This can cause the vmcore generated via 'kexec-tools' to miss the last few bytes as the first '/proc/iomem' starts from a non-zero address. Please see [0] for the original bug-report from Yanjiang Jin. The same can be fixed in the following manner: 1. For newer kernel (>= 4.19, with commit 23c85094fe1895caefdd ["proc/kcore: add vmcoreinfo note to /proc/kcore"] available), 'kcore' contains a new PT_NOTE which carries the VMCOREINFO information. If the same is available, one should prefer the same to retrieve 'PHYS_OFFSET' value exported by the kernel as this is now the standard interface exposed by kernel for sharing machine specific details with the user-land as per the arm64 kernel maintainers (see [1]) . 2. For older kernels, we can try and determine the PHYS_OFFSET value from PT_LOAD segments inside 'kcore' via some jugglery of the correct virtual and physical address combinations. As a fallback, we still support getting the PHYS_OFFSET values from '/proc/iomem', to maintain backward compatibility. Testing: ------- - Tested on my apm-mustang and qualcomm amberwing board with upstream kernel (4.20.0-rc7) for both KASLR and non-KASLR boot cases. References: ----------- [0] https://www.spinics.net/lists/kexec/msg20618.html [1] https://www.mail-archive.com/kexec@lists.infradead.org/msg20300.html Reported-by: Yanjiang Jin <yanjiang.jin@hxt-semitech.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09util_lib: Add functionality to read elf notesBhupesh Sharma
'vmcore-dmesg.c' already implements functionality to read 'vmcoreinfo' from vmcore file. The same can be used in other features as well (one of which is reading the elf notes from 'kcore' file), so there is merit in moving this to the utility libraries (util_lib). Newer kernel versions (>= 4.19, with commit 23c85094fe1895caefdd ["proc/kcore: add vmcoreinfo note to /proc/kcore"], available), have 'kcore' which now contains a new PT_NOTE which carries the VMCOREINFO information. If the same is available, we can benefit by using it in 'kexec-tools'. This is especially useful for architectures like arm64 as we can get kernel symbols like 'PHYS_OFFSET' from the '/proc/kcore' itself and use it to calculate 'phys_offset' before we make a call to 'set_phys_offset()'. For older kernels, we can try and determine the PHYS_OFFSET value from PT_LOAD segments inside 'kcore' via some jugglery of the correct virtual and physical address combinations. Subsequent patch(es) in this series will use the same feature to read the 'kcore' file. This patch also makes some of the functions which were earlier present in 'vmcore-dmesg.c' as non-static, so as to allow future patches to use them as library functions. Also we add the capability to read 'NUMBER(PHYS_OFFSET)' from vmcoreinfo to the already present 'scan_vmcoreinfo()' code. Future patches can look at reading more vmcoreinfo information (for e.g. 'kaslr_offset()' for x86_64 and arm64) by using the same framework. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09kexec/dt-ops.c: Fix '/chosen' v/s 'chosen' node being passed to fdt helper ↵Bhupesh Sharma
functions This patch fixes the incorrect 'chosen' node name being passed to various fdt helper functions inside 'kexec/dt-ops.c' As we can see from the Linux kernel usage inside 'drivers/firmware/efi/libstub/fdt.c', we pass '/chosen' node names to fdt helper function like 'fdt_path_offset()' whereas 'chosen' to the rest of the fdt helper functions like 'fdt_subnode_offset()'. We need to replicate the same in 'kexec-tools' to fix issues being reported when we use --dtb option while invoking 'kexec'. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09kexec/dt-ops.c: Fix adding '/chosen' node for cases where it is not ↵Bhupesh Sharma
available in dtb passed via --dtb option While calling 'kexec -l', in case we are passed a .dtb using --dtb option which doesn't contain a '/chosen' node, we try to create the '/chosen' node and add bootargs to this node. Currently the 'dt-ops.c' code is buggy as it passes '-FDT_ERR_NOTFOUND' to 'fdt_add_subnode()', which leads to the following error: # kexec -d --load Image --append 'debug' --dtb rk3399-sapphire.dtb <..snip..> dtb_set_property: fdt_add_subnode failed: FDT_ERR_NOTFOUND kexec: Set device tree bootargs failed. get_cells_size: #address-cells:2 #size-cells:2 cells_size_fitted: 0-0 cells_size_fitted: 0-0 setup_2nd_dtb: no kaslr-seed found This patch passes the correct nodeoffset value to 'fdt_add_subnode()', which fixes this issue: # kexec -d -l Image --append 'debug' --dtb rk3399-sapphire.dtb <..snip..> get_cells_size: #address-cells:2 #size-cells:2 cells_size_fitted: 0-0 cells_size_fitted: 0-0 setup_2nd_dtb: no kaslr-seed found Reported-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09kexec/kexec-arm64.c: Add error handling check against return value of ↵Bhupesh Sharma
'set_bootargs()' This patch adds missing error handling check against the return value of 'set_bootargs()' in 'kexec-arm64.c' Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09kexec/dt-ops.c: Fix check against 'fdt_add_subnode' return valueBhupesh Sharma
Vicenç reported (via [1]) that currently executing kexec with '--dtb' option and passing a .dtb which doesn't have a '/chosen' node leads to the following error: # kexec -d --dtb dtb_without_chosen_node.dtb --append 'cmdline' --load Image dtb_set_property: fdt_add_subnode failed: <valid offset/length> kexec: Set device tree bootargs failed. This happens because currently we check the return value of 'fdt_add_subnode()' function call in 'dt-ops.c' incorrectly: result = fdt_add_subnode(new_dtb, nodeoffset, node); if (result) { dbgprintf("%s: fdt_add_subnode failed: %s\n", _func__, fdt_strerror(result)); goto on_error; } As we can see in 'fdt_rw.c', a positive return value from 'fdt_add_subnode()' function doesn't indicate an error. We can see that the Linux kernel (see 'drivers/firmware/efi/libstub/fdt.c' for example) also checks the 'fdt_add_subnode()' function against negative return values for errors. See an example below from 'update_fdt()' function in 'drivers/firmware/efi/libstub/fdt.c': node = fdt_add_subnode(fdt, 0, "chosen"); if (node < 0) { status = node; <..snip..> goto fdt_set_fail; } This patch fixes the same in 'kexec-tools'. [1]. http://lists.infradead.org/pipermail/kexec/2018-October/021746.html Cc: Simon Horman <horms@verge.net.au> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Reported-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-11-15kexec-tools 2.0.18.gitSimon Horman
Add .git to version so it doesn't look like a release. This is just so when people build code from git it can be identified as such from the version string. Signed-off-by: Simon Horman <horms@verge.net.au>
2018-10-30kexec-tools 2.0.18Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2018-10-29arm64: If 'getrandom' syscall fails, don't error out - just warn and proceed.Bhupesh Sharma
For calculating the random 'kaslr-seed' value to be passed to the secondary kernel (kexec or kdump), we invoke the 'getrandom' syscall inside 'setup_2nd_dtb()' function. Normally on most arm64 systems this syscall doesn't fail when the initrd scriptware (which arms kdump service) invokes the same. However, recently I noticed that on the 'hp-moonshot' arm64 boards, we have an issue with the newer kernels which causes the same to fail. As a result, the kdump service fails and we are not able to use the kdump infrastructure just after boot. As expected, once the random pool is sufficiently populated and we launch the kdump service arming scripts again (manually), then the kdump service is properly enabled. Lets handle the same, by not error'ing out if 'getrandom' syscall fails. Rather lets warn the user and proceed further by setting the 'kaslr-seed' value as 0 for the secondary kernel - which implies that it boots in a 'nokaslr' mode. Tested on my 'hp-moonshot' and 'qualcomm-amberwing' arm64 boards. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-10-29x86: fix BAD_FREE in get_efi_runtime_map()Pingfan Liu
If the err_out label is reached, address of a stack variable is passed to free(). Fix it. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-10-10kexec-tools 2.0.18-rc1Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2018-10-02kdump: fix an error that can not parse the e820 reserved regionLianbo Jiang
When kexec-tools load the kernel and initramfs for kdump, kexec-tools will read /proc/iomem and recreate the e820 ranges for kdump kernel. But it fails to parse the e820 reserved region, because the memcmp() is case sensitive when comparing the string. In fact, it may be "Reserved" or "reserved" in the /proc/iomem, so we have to fix these cases. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Reviewed-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-08-24kexec: fix for "Unhandled rela relocation: R_X86_64_PLT32" errorChris Clayton
In response to a change in binutils, commit b21ebf2fb4c (x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to the linux kernel during the 4.16 development cycle and has since been backported to earlier stable kernel series. The change results in the failure message in $SUBJECT when rebooting via kexec. Fix this by replicating the change in kexec. Signed-off-by: Chris Clayton <chris2553@googlemail.com> Acked-by: Baoquan He <bhe@redhat.com> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Acked-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-06-29arm64: error out if kernel command line is too longMunehisa Kamata
Currently, in arm64, kexec silently truncates kernel command line longer than COMMAND_LINE_SIZE - 1. Error out in that case as some other architectures already do that. The error message is copied from x86_64. Suggested-by: Tom Kirchner <tjk@amazon.com> Signed-off-by: Munehisa Kamata <kamatam@amazon.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-06-29arm64: increase command line size to 2048Munehisa Kamata
Otherwise, we can hit the current 512 chars limit before hitting the Linux kernel's one, where allows 2048 chars in arm64. Signed-off-by: Munehisa Kamata <kamatam@amazon.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-06-19arm64: Add support to supply 'kaslr-seed' to secondary kernelBhupesh Sharma
This patch adds the support to supply 'kaslr-seed' to secondary kernel, when we do a 'kexec warm reboot to another kernel' (although the behaviour remains the same for the 'kdump' case as well) on arm64 platforms using the 'kexec_load' invocation method. Lets consider the case where the primary kernel working on the arm64 platform supports kaslr (i.e 'CONFIG_RANDOMIZE_BASE' was set to y and we have a compliant EFI firmware which supports EFI_RNG_PROTOCOL and hence can pass a non-zero (valid) seed to the primary kernel). Now the primary kernel reads the 'kaslr-seed' and wipes it to 0 and uses the seed value to randomize for e.g. the module base address offset. In the case of 'kexec_load' (or even kdump for brevity), we rely on the user-space kexec-tools to pass an appropriate dtb to the secondary kernel and since 'kaslr-seed' is wiped to 0 by the primary kernel, the secondary will essentially work with *nokaslr* as 'kaslr-seed' is set to 0 when it is passed to the secondary kernel. This can be true even in case the secondary kernel had 'CONFIG_RANDOMIZE_BASE' and 'CONFIG_RANDOMIZE_MODULE_REGION_FULL' set to y. This patch addresses this issue by first checking if the device tree provided by the firmware to the kernel supports the 'kaslr-seed' property and verifies that it is really wiped to 0. If this condition is met, it fixes up the 'kaslr-seed' property by using the getrandom() syscall to get a suitable random number. I verified this patch on my Qualcomm arm64 board and here are some test results: 1. Ensure that the primary kernel is boot'ed with 'kaslr-seed' dts property and it is really wiped to 0: [root@qualcomm-amberwing]# dtc -I dtb -O dts /sys/firmware/fdt | grep -A 10 -i chosen chosen { kaslr-seed = <0x0 0x0>; ... } 2. Now issue 'kexec_load' to load the secondary kernel (let's assume that we are using the same kernel as the secondary kernel): # kexec -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline -d 3. Issue 'kexec -e' to warm boot to the secondary: # kexec -e 4. Now after the secondary boots, confirm that the load address of the modules is randomized in every successive boot: [root@qualcomm-amberwing]# cat /proc/modules sunrpc 524288 1 - Live 0xffff0307db190000 vfat 262144 1 - Live 0xffff0307db110000 fat 262144 1 vfat, Live 0xffff0307db090000 crc32_ce 262144 0 - Live 0xffff0307d8c70000 ... Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-05-29Remove obsolete kdump toolBhupesh Sharma
The kdump tool presently allows one to generate an ELF file containing the ELF header, PT_NOTE and PT_LOAD segments (which can be analyzed later by tools like 'readelf') of the crashdump read from memory, when passed with an appropriate 'elfcorehdr' value(which represents the physical address of the start of the ELF header). With the availability of tools like crash/gdb the analysis of the crashdump core has become rather easy, and it makes the kdump tool obsolete. Also the same naming convention (man page) causes confusion when compared to similarly named distribution specific kdump service/utilities. Also most distributions (like Fedora for e.g.) now support more enhanced kdump service and utilities which can be used to analyze the crashdump core contents better. Taking an example of the Fedora specific kdump service and utilities, the following sequence of steps happen when the primary kernel crashes: 1. If the crashkernel is loaded, then the system starts executing the same. 2. When the boot process gets to the point when kdump service is started, the crashdump core is usually copied out to disk (for e.g. inside '/var/crash') using 'cp' command from '/proc/vmcore': # cp /proc/vmcore <dump-file> 3. Thereafter the system is rebooted back into the normal kernel. 4. Once back to your normal kernel, one can use the crashdump core available on hard disk in conjunction with the previously installed kernel (with debuginfo) to perform postmortem analysis with tools like gdb/crash: # gdb vmlinux <dump-file> Accordingly, this patch removes the obsolete kdump tool from 'kexec-tools'. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Reviewed-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-05-25Makefile.in: Add uninstall ruleBhupesh Sharma
Presently the Makedumpfile.in doesn't include a uninstall rule, which is useful in case we want to preform a reverse of the install process done by Makefile.in This patch adds this rule, thus making it easier to remove installed executables and man pages in case one needs to uninstall the same. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-05-25vmcore-dmesg: fix infinite loop if log buffer wraps aroundOmar Sandoval
We hit a bug where vmcore-dmesg would get stuck in a loop, and since we were redirecting the output to a file, it wouldn't stop until it filled up the disk. This only happened when the dmesg buffer had filled up and wrapped around. It turns out that when we hit the end of the buffer, we are looping back to the first record instead of the beginning of the buffer, which will always loop forever. Fixes: e08d26b3b7f1 ("vmcore-dmesg: avoid allocating large memory chunk for log buf") Signed-off-by: Omar Sandoval <osandov@fb.com> Acked-by: Baoquan He <bhe@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-05-22kexec/s390: Add support for kexec_file_loadPhilipp Rudo
Since kernel 4.17-rc2 s390 supports the kexec_file_load system call. Add the new system call to kexec-tools and provide the -s (--kexec-file-syscall) option for s390 to support this new feature. Signed-off-by: Philipp Rudo <prudo@linux.ibm.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-19kexec: Add --no-checks optionGeoff Levand
Add a new option --no-checks to kexec that allows for a fast reboot by avoiding the purgatory integrity checks. This option is intended for use by kexec based bootloaders that load a new image and then immediately transfer control to it. Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-19purgatory/ppc64: Fix uninitialized warningGeoff Levand
Fixes warnings like these when building kexec for powerpc (32 bit): console-ppc64.c: warning: ‘*((void *)&buff+8)’ may be used uninitialized Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-19kexec-elf-rel-ppc64: Fix cast from pointer warningGeoff Levand
Fixes warnings like these when building kexec for powerpc (32 bit): kexec-elf-rel-ppc64.c: warning: cast from pointer to integer of different size Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-19crashdump-ppc64: Fix integer truncation warningGeoff Levand
Fixes warnings like these when building kexec for powerpc (32 bit): crashdump-ppc64.h: warning: large integer implicitly truncated to unsigned type Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-19kexec: Fix printf warningGeoff Levand
Fixes warnings like these when building kexec for powerpc (32 bit): kexec.c: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘uint64_t Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-19kexec-tools 2.0.17.gitSimon Horman
Add .git to version so it doesn't look like a release. This is just so when people build code from git it can be identified as such from the version string. Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-19kexec-tools 2.0.17Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-19arm64: Set -fno-PIC along with -mcmodel=largeDavid Michael
As seen in GCC's gcc/config/aarch64/aarch64.c, -fPIC with large code model is unsupported. This fixes the "sorry, unimplemented" errors when building with compilers defaulting to -fPIC. Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: David Michael <david.michael@coreos.com>
2018-04-19Merge branch 'master' of git://git.armlinux.org.uk/~rmk/kexec-toolsSimon Horman
2018-04-10kexec-tools 2.0.17-rc1Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-10Fix a segmentation fault when trying to run "kexec -p"Petr Tesarik
Do not fall through to "--mem-min" when "-p" option is parsed. The break statement was apparently removed by mistake... Fixes: cb434cbe6f40 ("kexec: Do not special-case the -s option") Signed-off-by: Petr Tesarik <ptesarik@suse.com> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-04-10arm64: fix an issue with kaslr-enabled vmlinuxAKASHI Takahiro
Normally vmlinux for arm64 is of ET_EXEC type, while if built with CONFIG_RANDAMIZE_BASE (that is KASLR), it will be of ET_DYN type. Meanwhile, physical address field of segments in vmlinux has actually the same value as virtual address field. Accordingly, in this case, it totally makes no sense to check for validity of segments against physical memory ranges and, if necessary, relocate them in elf_exec_load() on arm64. This patch allows to unconditionally skip the check on arm64. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-03-30kexec: Document -s, -c and -a options in the man pageMichal Suchanek
Signed-off-by: Michal Suchanek <msuchanek@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-03-30kexec: Add option to fall back to KEXEC_LOAD when KEXEC_FILE_LOAD is not ↵Michal Suchanek
supported Not all architectures implement KEXEC_FILE_LOAD. However, on some archiectures KEXEC_FILE_LOAD is required when secure boot is enabled in locked-down mode. Previously users had to select the KEXEC_FILE_LOAD syscall with undocumented -s option. However, if they did pass the option kexec would fail on architectures that do not support it. So add an -a option that tries KEXEC_FILE_LOAD and when it is not supported tries KEXEC_LOAD. Signed-off-by: Michal Suchanek <msuchanek@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-03-30kexec: Add option to revert -sMichal Suchanek
The undocumented -s option selects KEXEC_FILE_LOAD syscall but there is no option to select KEXEC_LOAD syscall. Add it so -s can be reverted. Signed-off-by: Michal Suchanek <msuchanek@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-03-30kexec: Do not special-case the -s optionMichal Suchanek
It is parsed separately to save a few CPU cycles when setting up other options but it just complicates the code. So fold it back and set up all flags for both KEXEC_LOAD and KEXEC_FILE_LOAD Signed-off-by: Michal Suchanek <msuchanek@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-03-30kexec: Fix option checks to take KEXEC_FILE_LOAD into accountMichal Suchanek
When kexec_file_load support was added some sanity checks were not updated. Some options are set only in the kexec_load flags so cannot be supported wiht kexec_file_load. On the other hand, reserved memory is needed for kdump with both kexec_load and kexec_file_load. Signed-off-by: Michal Suchanek <msuchanek@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-03-30kexec: Return -ENOSYS when kexec does not know how to call KEXEC_FILE_LOADMichal Suchanek
When the kernel does not know a syscall number it returns -ENOSYS but when kexec does not know a syscall number it returns -1. Return -ENOSYS from kexec as well. Signed-off-by: Michal Suchanek <msuchanek@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-03-30kexec/ppc64: leverage kexec_file_load supportHari Bathini
PPC64 kernel now supports kexec_file_load system call. Leverage it by enabling that support here. Note that loading crash kernel with this system call is not yet supported in the kernel and trying to load one will fail with '-ENOTSUPP' error. Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-03-20ARM: Include stack and malloc space in zImage sizeRussell King
Include the stack and malloc space in our calculation of the zImage size, both of which must be avoided when locating the dtb. Signed-off-by: Russell King <rmk@armlinux.org.uk>
2018-03-20ARM: add further debugRussell King
Add further debugging of the kernel size Signed-off-by: Russell King <rmk@armlinux.org.uk>
2018-03-20ARM: read kernel size from zImageRussell King
Signed-off-by: Russell King <rmk@armlinux.org.uk>
2018-02-22kexec/ppc64: add support to parse ibm, dynamic-memory-v2 propertyHari Bathini
Add support to parse the new 'ibm,dynamic-memory-v2' property in the 'ibm,dynamic-reconfiguration-memory' node. This replaces the old 'ibm,dynamic-memory' property and is enabled in the kernel with a patch series that starts with commit 0c38ed6f6f0b ("powerpc/pseries: Enable support of ibm,dynamic-memory-v2"). All LMBs that share the same flags and are adjacent are grouped together in the newer version of the property making it compact to represent larger memory configurations. Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-02-22kexec: add a helper function to add rangesHari Bathini
Add a helper function for adding ranges to avoid duplicating code. Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-01-29x86: use old screen_info if neededDave Young
With modern drm/kms graphic driver kexec-tools does not setup screen_info correctly so one will only see screen output after those drm drivers reinitializing after rebooting. Copying the old screen info from original boot_params will help during my test, although it could not work for some potential cases, but it is not worse than before. This has been used in the kernel kexec_file_load. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-01-25kexec-tools: Make xc_dlhandle staticEric DeVolder
This patch is a follow-on to commit 894bea93 "kexec-tools: Perform run-time linking of libxenctrl.so". This patch addresses feedback from Daniel Kiper. This patch implements Daniel's suggestion to make the xc_dlhandle variable static, insert missing 'extern' qualifier for the new __xc() wrappers, and correct some style issues. Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
generated by cgit (git 2.34.1) at 2025-07-16 18:02:14 +0000