summaryrefslogtreecommitdiff
path: root/kexec/arch
AgeCommit message (Collapse)Author
2014-05-11cleanup duplicate codeWANG Chao
I accidentally add one duplicate line. Now remove it. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-05-11zImage-arm: bugfix: kernel offset must be 0x8000Wang Nan
This patch fixs a problem introduced by commit e5d6a55 which make ARM kexec fails. Due to that commit, kernel is loaded at a dynamically offset: it computes extra_size using size of dtb, and load zImage at base + extra_size. When dtb size small (for example, 0x3000 bytes), kernel will be loaded at address like 0x60003000. For ARM zImage such address is incorrect. In kernel code arch/arm/boot/compressed/head.S, zImage builds a temporary page table at (pc & 0xf8000000) + TEXT_OFFSET - 0x4000. The related instructions sequence is: mov r4, pc and r4, r4, #0xf8000000 add r4, r4, #TEXT_OFFSET @ (TEXT_OFFSET == 0x8000 on most platforms) call cache_on ... call __armv7_mmu_cache_on ... call __setup_mmu sub r3, r4, #16384 @ Page directory size r3 becomes page table pointer. When kernel is loaded at 0x60003000, page table is still built at 0x60004000, which destroys kernel. This patch make extra_size a fix value (0x8000) to avoid the failure. For the problem commit e5d6a55 tries solve, this patch uses locate_holes() to find a place can hold initrd and dtb. Change from v1: - Coding style enhancements. Signed-off-by: Wang Nan <wangnan0@huawei.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-05-11condition check fixWANG Chao
In commit 91f5b9c ("kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data"), I made a wrong condition check. We should only add cmdline for a memory range if --pass-memmap-cmdline and the range type isn't RANGE_RESERVED. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-05-02zImage-arm: get rid of static offsetDaniel Mack
The code in arch/arm/kexec-zImage-arm.c currently enforces a hard limit on the maximum size a dtb blob can occupy. This limit is set to 32k, which is quite low for device tree blobs nowadays. Get rid of this assumption, and calculate the added size dynamically. For this, we need to slurp in the dtb file earlier in order to determine its size, because the memory hole allocation for 'base' takes this size into account. For ATAGs, we keep the current value of 32k, which should in fact be enough. With this change in place, the 'DTB too large!' error message can go away. Successfully tested on a AM335x board. Signed-off-by: Daniel Mack <zonque@gmail.com> [s.neumann@raumfeld.com: Fix ATAGs case] Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-29kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_dataWANG Chao
e820 reserved region could be useful in 2nd kernel. For example, PCI mmconf (extended mode) requires reserved region otherwise it falls back to legacy mode. The following log is from Cliff Wickman <cpw@sgi.com>: PCI: MMCONFIG for domain 1003 [bus 3f-3f] at [mem 0xff0ff00000-0xff0fffffff] (base 0xff0c000000) [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources PCI: not using MMCONFIG PCI devices on segment 1 (>0) can't fall back to legacy mode, thus kernel probing fails and device can't be found. We don't pass reserved region because these regions could be too much and eat up our very limited kernel command line resource in memmap=exactmap case. However now we use e820 map and setup_data to pass memory map to 2nd kernel and the number of reserved regions should not be a problem any more. Signed-off-by: WANG Chao <chaowang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86: Pass memory range via E820 for kdumpWANG Chao
command line size is restricted by kernel, sometimes memmap=exactmap has too many memory ranges to pass to cmdline. And also memmap=exactmap and kASLR doesn't work together. A better approach, to pass the memory ranges for crash kernel to boot into, is filling the memory ranges into E820. boot_params only got 128 slots for E820 map to fit in, when the number of memory map exceeds 128, use setup_data to pass the rest as extended E820 memory map. kexec boot could also benefit from setup_data in case E820 memory map exceeds 128. Now this new approach becomes default instead of memmap=exactmap. saved_max_pfn users can specify --pass-memmap-cmdline to use the exactmap approach. Signed-off-by: WANG Chao <chaowang@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Reviewed-by: Linn Crosetto <linn@hp.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86: add --pass-memmap-cmdline optionWANG Chao
--pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd kernel. Later we will use this option to disable passing E820 memmap method but use the old exactmap method. Signed-off-by: WANG Chao <chaowang@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86, cleanup: kexec memory range .end to be inclusiveWANG Chao
Later kexec and kdump memory range will be mapped to E820entry. But currently kexec memory range .end field is exclusive while crash memory range is inclusive. Given the fact that the exported proc iomem and sysfs memmap are both inclusive, change kexec memory range .end to be inclusive. Later the unified memory range of both kexec and kdump can use the same E820 filling code. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86, cleanup: Store crash memory ranges kexec_infoWANG Chao
Add two new members to kexec_info structure: struct memory_range *crash_range int nr_crash_ranges; crash_range contains the memory ranges used to boot 2nd kernel. nr_crash_ranges contains the count of the crash memory ranges. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86, cleanup: use dbgprint_mem_range for memory range debuggingWANG Chao
Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86, cleanup: increase CRASH_MAX_MEMMAP_NR up to 1024WANG Chao
CRASH_MAX_MEMMAP_NR is used as the upper boundary of memmap_p. Originally memmap_p was used to store RANGE_RAM only. But now we changed it to store all the types of memory ranges for 2nd kernel, which includes RANGE_RAM, RANGE_ACPI, RANGE_ACPI_NVS (and RANGE_RESERVED in the future). Currently CRASH_MAX_MEMMAP_NR is defined (KEXEC_MAX_SEGMENTS + 2), which is not enough for memmap_p. It must be increased to a much higher value. I think 1024 is good enough for storing all memory ranges for 2nd kernel. So this patch increases CRASH_MAX_MEMMAP_NR to 1024. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86, cleanup: add other types of memory range for 2nd kernel boot to memmap_pWANG Chao
In load_crashdump_segments(), memmap_p[] is used to contain RANGE_RAM memory range for booting 2nd kernel. Now adding types of RANGE_ACPI and RANGE_ACPI_NVS to memmap_p, so later we can pass all the types of memory range to 2nd kernel. These all types of memory ranges are all stored in memmap_p for later reference. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86, cleanup: add_memmap() only do alignment check on RANGE_RAMWANG Chao
add_memmap() will also add memory range with type RANGE_ACPI and RANGE_ACPI_NVS (RANGE_RESERVED in the future) besides RANGE_RAM to memmap_p. Among these types of memory range, only RANGE_RAM needs to be aligned with certain alignment. RANGE_ACPI, RANGE_ACPI_NVS and RANGE_RESERVED doesn't have to be aligned. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86, cleanup: add extra arguments to add_memmap() and delete_memmap()WANG Chao
This change will be used later: add_memmap(.., int *nr_memmap, .., int type); delete_memmap(.., int *nr_memmap, ..); memmap_p[] is statically allocated for a certain amount. It will be used later when mapping these memory maps to e820 map. It's convenient to keep track of the count of memmap_p (nr_memmap) in add_memmap and delete_memmap, because the counting has already been taken care of in these two functions. The original add_memmap() can only add memory range of RANGE_RAM type. For adding other types of memory range, add another argument for indicating the type. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-14x86, cleanup: Add a funtion add_setup_data()WANG Chao
add_setup_data() is used to add an instance to the single linked list of setup_data structure. Signed-off-by: WANG Chao <chaowang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-14x86, cleanup: fix indentWANG Chao
Signed-off-by: WANG Chao <chaowang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-10kexec/ppc: cleanup crash regions creationNikita Yushchenko
Move filling crash_memory_range table entries into a separate routine, which saves quite a few lines of code. In this routine, if range spawns over lowmem-highmem border, split range into two. This is needed to get proper virtual address for lowmem part. Similar thing is already done for x86. Credits to Yadviga Grigorieva <yadviga@dev.rtsoft.ru> for tracking down this issue for ppc. Also this patch makes excluding crash kernel regoin a bit shorter, and removes unused variable to get rid of compiler warning. Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-03-28Pass initrd position by dtbWang Nan
This patch append the position of initrd to dtb when loading arm kernel and initrd without using atag. Signed-off-by: Wang Nan <wangnan0@huawei.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-03-28Introduce setup_dtb_prop to make code clearWang Nan
This patch introduces setup_dtb_prop(), which is used for dtb operations. The code is extracted from zImage_arm_load, and this patch makes memory grown computation more accurate. Signed-off-by: Wang Nan <wangnan0@huawei.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-03-28x86, kaslr: add alternative way to locate kernel text mapping areaWANG Chao
When kASLR is enabled (CONFIG_RANDOMIZED_BASE=y), kernel text mapping base is randomized. The max base offset of such randomization is configured at compile time through CONFIG_RANDOMIZE_MAX_BASE_OFFSET (by default 1G). Currently kexec-tools is using hard code macro X86_64__START_KERNEL_map (0xffffffff80000000) and X86_64_KERNEL_TEXT_SIZE (512M) to determine kernel text mapping from kcore's PT_LOAD. With kASLR, the mapping is changed as the following: ffffffff80000000 - (ffffffff80000000+CONFIG_RANDOMIZE_BASE_MAX_OFFSET) As Vivek suggested, we can get _stext kernel symbol address from /proc/kallsyms, and search for kcore's PT_LOAD which contains _stext, and we can say that this area represents the kernel mapping area. Let's first use this way to find out kernel text mapping. If failed for whatever reason, fall back to use the old way. Suggested-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-03-28i386: fix erroneous memory descriptor messageTony Jones
On non-EFI systems, efi_info section of boot_params is zero filled resulting in an erroneous message from kexec regarding "efi memory descriptor" version. Caused by commit: e1ffc9e9a0769e1f54185003102e9bec428b84e8 "Passing efi related data via setup_data" 0000700 0000 0000 0000 0000 0000 0000 0000 0000 0000720 0000 0000 0000 0000 0000 0000 0000 0000 0000740 efi memory descriptor version 0 is not supported! Signed-off-by: Tony Jones <tonyj@suse.de> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-03-25kexec-tools: handle 64bit efi memmap address correctlyDave Young
In case using crashkernel=xM,high crashkernel memory will be allocated from top to down Thus the usable memory for kdump kernel could be bigger than 4G. The efi memmap value is two 32 bit values efi_memmap and efi_memmap_hi, previously I only passed the efi_memmap so for the high memory address there will be below kernel panic: [ 0.000000] efi: EFI v2.31 by American Megatrends [ 0.000000] efi: ACPI 2.0=0xdb752000 SMBIOS=0xdbab4b98 ACPI=0xdb752000 MPS=0xf4bd0 [ 0.000000] efi: mem00: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] efi: mem01: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] efi: mem02: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] efi: mem03: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] efi: mem04: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] SMBIOS 2.7 present. [snip] [ 0.082451] BUG: unable to handle kernel paging request at ffffa3d0f0000000 [ 0.089467] IP: [<ffffffff810513d1>] native_set_pte+0x1/0x10 [ 0.095157] PGD 0 [ 0.097197] Oops: 0002 [#1] SMP [ 0.100466] Modules linked in: [ 0.103554] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc7 #157 [ 0.110001] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013 [ 0.118697] task: ffffffff818e1460 ti: ffffffff818ce000 task.ti: ffffffff818ce000 [ 0.126181] RIP: 0010:[<ffffffff810513d1>] [<ffffffff810513d1>] native_set_pte+0x1/0x10 [ 0.134296] RSP: 0000:ffffffff818cfc80 EFLAGS: 00010287 [ 0.139609] RAX: 0000000000000000 RBX: ffffa3d0f0000000 RCX: 00003ffffffff000 [ 0.146744] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffffa3d0f0000000 [ 0.153879] RBP: ffffffff818cfcb8 R08: ffffea0010745d20 R09: 0000000000000000 [ 0.161013] R10: ffff88041f731fc0 R11: 000000000000001e R12: 0000000000200000 [ 0.168148] R13: 0000000000000000 R14: 0000000000400000 R15: ffff880000000008 [ 0.175288] FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000 [ 0.183377] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.189125] CR2: ffffa3d0f0000000 CR3: 000000041e8da000 CR4: 00000000000406b0 [ 0.196264] Stack: [ 0.198283] ffffffff818cfcb8 ffffffff810561d7 ffff880000000008 0000000000400000 [ 0.205746] ffff880000001000 00000000000001ff ffff88041e8de000 ffffffff818cfd00 [ 0.213210] ffffffff8105644e 0000000000200000 0000000040000000 00000000ffffffff [ 0.220676] Call Trace: [ 0.223130] [<ffffffff810561d7>] ? unmap_pte_range+0x77/0x110 [ 0.228966] [<ffffffff8105644e>] unmap_pmd_range+0xde/0x210 [ 0.234630] [<ffffffff81056c6b>] __cpa_process_fault+0x48b/0x5e0 [ 0.240730] [<ffffffff81057276>] __change_page_attr_set_clr+0x4b6/0xb10 [ 0.247437] [<ffffffff810557c7>] ? __ioremap_caller+0x277/0x360 [ 0.253454] [<ffffffff810589f1>] kernel_map_pages_in_pgd+0x71/0xa0 [ 0.259736] [<ffffffff81a53361>] __map_region+0x45/0x63 [ 0.265051] [<ffffffff81a535cc>] efi_map_region_fixed+0xd/0xf [ 0.270886] [<ffffffff81a52f19>] efi_enter_virtual_mode+0x5a/0x3d9 [ 0.277162] [<ffffffff81a77516>] ? acpi_enable_subsystem+0x37/0x90 [ 0.283440] [<ffffffff81a36eb9>] start_kernel+0x386/0x41c [ 0.288931] [<ffffffff81a3693c>] ? repair_env_string+0x5c/0x5c [ 0.294852] [<ffffffff81a36120>] ? early_idt_handlers+0x120/0x120 [ 0.301035] [<ffffffff81a365ee>] x86_64_start_reservations+0x2a/0x2c [ 0.307479] [<ffffffff81a3672e>] x86_64_start_kernel+0x13e/0x14d [ 0.313572] Code: 66 2e 0f 1f 84 00 00 00 00 00 48 8b 46 18 55 48 89 e5 48 89 47 04 5d c3 66 90 55 48 89 e5 0f 01 f8 5d c3 0f 1f 8 [ 0.333545] RIP [<ffffffff810513d1>] native_set_pte+0x1/0x10 [ 0.339312] RSP <ffffffff818cfc80> [ 0.342807] CR2: ffffa3d0f0000000 [ 0.346141] ---[ end trace 86088f739725b8c6 ]--- [ 0.350760] Kernel panic - not syncing: Fatal exception Fix this by passing both efi_memmap and efi_memmap_hi to 2nd kernel. Reported-by: Linn Crosetto <linn@hp.com> Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-03-20kexec: align initrd when no --image-size passedWang Nan
Before this patch, when no --image-size passed, initrd_base is caculated using base + len * 4, which is unaligned, and unable to pass check in add_segment_phys_virt(): if (base & (pagesize -1)) { die("Base address: 0x%lx is not page aligned\n", base); } This patch also uses getpagesize() instead of hard encoded 4096. Signed-off-by: Wang Nan <wangnan0@huawei.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-03-20cleanup: add dbgprint_mem_range functionWANG Chao
dbgprint_mem_range is used for printing the given memory range under debugging mode. Signed-off-by: WANG Chao <chaowang@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-02-06zImage_ppc64_probe: return 0 instead of 1 in case of successDave Young
All other _probe functions return 0 for probing the kernel image successfully, so there's no reason to return 1 here. Fix it to return 0 instead. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-02-06i386: fix redefinition error for e820entryTony Jones
At least on our systems, xenctrl.h defines (unguarded) struct e820entry Move the (guarded) definition in include/x86/x86-linux.h to below. Signed-off-by: Tony Jones <tonyj@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-02-06i386: fix build failure (bzImage_support_efi_boot)Tony Jones
Commit 9c200a85de2245a850546fded96a1977b84ad24d referenced 'bzImage_support_efi_boot' without matching 32-bit definition. Signed-off-by: Tony Jones <tonyj@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-02-04kexec/ppc64 Enable early kernel's OPAL callsLaurent Dufour
When the kernel is built with CONFIG_PPC_EARLY_DEBUG_OPAL set, it is expecting to get r8 and r9 filled respectively with OPAL base address and OPAL entry address (arc/power/head_64.S). On the new powernv platform, having these 2 registers set allows the kernel to perform OPAL calls before it parse the device tree. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-02-04kexec/ppc64 ELF ABIv2 ABI supportLaurent Dufour
When building in PPC64 little endian mode, the compiler is now using the new ABI v2. Among other changes, this new ABI removes the function descriptors and changes the way the TOC address is computed when entering a C function. The purgatory assembly part where the dot symbols are removed, and ELF relocation code are impacted in this patch. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-31kexec/ppc64 fix device tree endianess issues for memory attributesLaurent Dufour
All the attributes exposed in the device tree are in Big Endian format. This patch add the byte swap operation for some entries which were not yet processed, including those fixed by the following kernel's patch : https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-January/114720.html To work on PPC64 Little Endian mode, kexec now requires that the kernel's patch mentioned above is applied on the kexecing kernel. Tested on ppc64 LPAR (kexec/dump) and ppc64le in a Qemu/KVM guest (kexec) Changes from v1 : * add processing of the following entries : - ibm,dynamic-reconfiguration-memory - chosen/linux,kernel-end - chosen/linux,crashkernel-base & size - chosen/linux,memory-limit - chosen/linux,htab-base & size - linux,tce-base & size - memory@/reg Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-21Passing efi related data via setup_dataDave Young
For supporting efi runtime, several efi physical addresses fw_vendor, runtime, config tables, smbios and the whole runtime mapping info need to be used in kexec kernel. Thus introduce setup_data struct for passing these data. collect the varialbes from /sys/firmware/efi/systab and /sys/firmware/efi/runtime-map Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-21Add efi_info in x86 setup headerDave Young
For supporting efi runtime on kexec kernel we need to fill the efi_info struct in setup_header. I just get the info in kernel exported boot_params data in debugfs. Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-21Add function get_bootparamDave Young
Not only setup_subarch will get data from debugfs file boot_params/data, later code for adding efi_info will also need do same thing. Thus add a common function here for later use. Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-21build fix: include x86-linux.h in x86-linux-setup.hDave Young
There's build warnings about using struct x86_linux_param_header * in x86-linux-setup.h, it is declared in x86-linux.h Fix it by include x86-linux.h in x86-linux-setup.h Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-16Fix value of mbi->mem_lower for multiboot-x86Peter Chubb
In the multiboot header, there is a field, `mem_lower' that is meant to contain the size of memory starting at zero and ending below 640k. If your kernel is compiled with CONFIG_X86_RESERVE_LOW non zero (the usual case), then a hole is inserted into kernel's physical memory map at zero, so the test to find the size of this region in kexec/arch/i386/kexec-multiboot-x86.c never succeeds, so the value is always zero. On a PC99 architecture, there is always memory at physycal address zero; assume that a region that starts below 64k actually starts at zero, and use it for the mem_lower variable. Signed-off-by: Peter Chubb <peter.chubb@nicta.com.au> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-14kexec: arm: Fix endianness in crashdump headerTaras Kondratiuk
Currently little-endian ELFDATA is hard-coded in crashdump header. This lead to a wrong header format if crashdump is generated on BE system. Set native endianness into ELFDATA field. Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-12-13kexec: Add m68k supportGeert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-12-13kexec: Let slurp_file_len() return the number of bytes readGeert Uytterhoeven
Add an optional output parameter to slurp_file_len() so it can return the actual number of bytes read. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-12-03kexec-tools/xen: Do not call xc_interface_close() if xc_interface_open() failedDaniel Kiper
Do not call xc_interface_close() if xc_interface_open() failed. xc_interface_close() crashes if it gets NULL as an argument. Relevant fix for libxenctrl will be posted too but kexec-tools should also behave properly. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-11-19kexec/xen: directly load images images into XenDavid Vrabel
Xen 4.4 has an improvided kexec hypercall ABI that allows images to be loaded and executed without any kernel involvement. Use the API provided by libxc to load images when running in a Xen guest. Support for loading images via the kexec_load syscall in non-upstream ("classic") Xen kernels is no longer supported. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-11-19kexec/xen: require libxc from Xen 4.4David Vrabel
libxc from Xen 4.4 added xc_kexec_load() which will be required to load images into Xen in the future. Remove all the #ifdef'ery for older versions of libxc. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-11-19kexec/ppc64: bring up new ppc64le architectureLaurent Dufour
This patch provides support for the new Power PC litte endian (LE) mode. The LE mode only differs in the way the instructions and data are stored in memory thus there is no real need to duplicate the ppc64 code. However some compilation's options, especially for the purgatory, differ between little and big endian mode's support. A new "SUBARCH" build variable is introduced which is currently only used for PPC64 to specify the endianness. Another set of changes in this patch is fixing minor endianess issues in the ppc64 code and fix an alignment issue raised on Power7 little endian mode. Among these fixes, the check on the kernel binary endianess is removed, since we can imagine kexecing a LE kernel from a BE environment, as far as the specified root filesystem and initrd file are containing the right binaries. This patch depends on the patch "kexec/ppc64: use common architecture fs2dt.c file" I sent earlier on the kexec mailing list. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-11-19kexec/ppc64: use common architecture fs2dt.c fileLaurent Dufour
Following the commit 'b3c2962 fs2dt: Add a generic copy of fs2dt' which introduced a generic fs2dt file, this patch is removing the ppc64 architecture's one. Tests have been done successfully on Power 7 plateform. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-11-14arm: add command line option for the total image sizeDaniel Mack
Currently, kexec on arm assumes that it's safe to place binary images such as atags, dtb or initrd at an estimated offset after the load address. That estimated offset is set to 4 times the size of the compressed image, hence assuming a minimum compression ratio of 1:4. While that assumption matches what the in-kernel compressors are able to achive, it doesn't take into account the .bss section the kernel image carries, and which can grow to arbitrary sizes while not accounting to the compressed image size. After decompression, and before the execution of the compressed kernel, the .bss area is initialized to zeros, trampeling over the binary images in case they happen to live in that piece of memory. Unfortunately, determining the full image size is not easiliy possible at runtime, as it would include doing all possible ways of decompression and then walk the ELF sections by hand. For now, allow users to override the static offset with a new, arm specific command line argument. Users are supposed to set this, and determine a sane value by using 'arm-linux-size vmlinux'. Signed-off-by: Daniel Mack <zonque@gmail.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-09-25kexec/ppc: Check for a uImage initrd with ELF kernelSuzuki K. Poulose
We should check if the initrd is in uImage format, when the kernel might be in ELF. Signed-off-by : Suzuki K Poulose <suzuki@in.ibm.com> Signed-off-by : Athira Rajeev<atrajeev@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-09-25kexec/ppc: Add nodes for initrd in dtbSuzuki K. Poulose
If the primary kernel doesn't use an initrd, we may not have linux,initrd-* entries in the device-tree, and hence the initial flat tree may not contain them. Make sure we add the entries in the dtb if the second kernel needs an initrd. Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Athira Rajeev<atrajeev@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-09-19cris: is_crashkernel_mem_reserved() should return 0Geert Uytterhoeven
Cris doesn't have support for crash kernels yet. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-09-19kexec: Fix cris/superh comment mixupsGeert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-09-19cris/mips: Remove unused setup_simple_* declarationsGeert Uytterhoeven
Presumably these had been copied from ppc. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Simon Horman <horms@verge.net.au>
generated by cgit (git 2.34.1) at 2025-07-18 12:49:58 +0000