| Age | Commit message (Collapse) | Author |
|---|
|
When kexec is utilized in a Xen environment, it has an explicit
run-time dependency on libxenctrl.so. This dependency occurs
during the configure stage and when building kexec-tools.
When kexec is utilized in a non-Xen environment (either bare
metal or KVM), the configure and build of kexec-tools omits
any reference to libxenctrl.so.
Thus today it is not currently possible to configure and build
a *single* kexec that will work in *both* Xen and non-Xen
environments, unless the libxenctrl.so is *always* present.
For example, a kexec configured for Xen in a Xen environment:
# ldd build/sbin/kexec
linux-vdso.so.1 => (0x00007ffdeba5c000)
libxenctrl.so.4.4 => /usr/lib64/libxenctrl.so.4.4 (0x00000038d8000000)
libz.so.1 => /lib64/libz.so.1 (0x00000038d6c00000)
libc.so.6 => /lib64/libc.so.6 (0x00000038d6000000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000038d6400000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038d6800000)
/lib64/ld-linux-x86-64.so.2 (0x000055e9f8c6c000)
# build/sbin/kexec -v
kexec-tools 2.0.16
However, the *same* kexec executable fails in a non-Xen environment:
# copy xen kexec to .
# ldd ./kexec
linux-vdso.so.1 => (0x00007fffa9da7000)
libxenctrl.so.4.4 => not found
liblzma.so.0 => /usr/lib64/liblzma.so.0 (0x0000003014e00000)
libz.so.1 => /lib64/libz.so.1 (0x000000300ea00000)
libc.so.6 => /lib64/libc.so.6 (0x000000300de00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000300e200000)
/lib64/ld-linux-x86-64.so.2 (0x0000558cc786c000)
# ./kexec -v
./kexec: error while loading shared libraries:
libxenctrl.so.4.4: cannot open shared object file: No such file or directory
At Oracle we "workaround" this by having two kexec-tools packages,
one for Xen and another for non-Xen environments. At Oracle, the
desire is to offer a single kexec-tools package that works in either
environment. To achieve this, kexec-tools would either have to ship
with libxenctrl.so (which we have deemed as unacceptable), or we can
make kexec perform run-time linking against libxenctrl.so.
This patch is one possible way to alleviate the explicit run-time
dependency on libxenctrl.so. This implementation utilizes a set of
macros to wrap calls into libxenctrl.so so that the library can
instead be dlopen() and obtain the function via dlsym() and then
make the call. The advantage of this implementation is that it
requires few changes to the existing kexec-tools code. The dis-
advantage is that it uses macros to remap libxenctrl functions
and do work under the hood.
Another possible implementation worth considering is the approach
taken by libvmi. Reference the following file:
https://github.com/libvmi/libvmi/blob/master/libvmi/driver/xen/libxc_wrapper.h
The libxc_wrapper_t structure definition that starts at line ~33
has members that are function pointers into libxenctrl.so. This
structure is populated once and then later referenced/dereferenced
by the callers of libxenctrl.so members. The advantage of this
implementation is it is more explicit in managing the use of
libxenctrl.so and its versions, but the disadvantage is it would
require touching more of the kexec-tools code.
The following is a list libxenctrl members utilized by kexec:
Functions:
xc_interface_open
xc_kexec_get_range
xc_interface_close
xc_kexec_get_range
xc_interface_open
xc_get_max_cpus
xc_kexec_get_range
xc_version
xc_kexec_exec
xc_kexec_status
xc_kexec_unload
xc_hypercall_buffer_array_create
xc__hypercall_buffer_array_alloc
xc_hypercall_buffer_array_destroy
xc_kexec_load
xc_get_machine_memory_map
Data:
xc__hypercall_buffer_HYPERCALL_BUFFER_NULL
These were identified by configuring and building kexec-tools
with Xen support, but omitting the -lxenctrl from the LDFLAGS
in the Makefile for an x86_64 build.
The above libxenctrl members were referenced via these source
files.
kexec/crashdump-xen.c
kexec/kexec-xen.c
kexec/arch/i386/kexec-x86-common.c
kexec/arch/i386/crashdump-x86.c
This patch provides a wrapper around the calls to the above
functions in libxenctrl.so. Every libxenctrl call must pass a
xc_interface which it obtains from xc_interface_open().
So the existing code is already structured in a manner that
facilitates graceful dlopen()'ing of the libxenctrl.so and
the subsequent dlsym() of the required member.
The patch creates a wrapper function around xc_interface_open()
and xc_interface_close() to perform the dlopen() and dlclose().
For the remaining xc_ functions, this patch defines a macro
of the same name which performs the dlsym() and then invokes
the function. See the __xc_call() macro for details.
There was one data item in libxenctrl.so that presented a
unique problem, HYPERCALL_BUFFER_NULL. It was only utilized
once, as
set_xen_guest_handle(xen_segs[s].buf.h, HYPERCALL_BUFFER_NULL);
I tried a variety of techniques but could not find a general
macro-type solution without modifying xenctrl.h. So the
solution was to declare a local HYPERCALL_BUFFER_NULL, and
this appears to work. I admit I am not familiar with libxenctrl
to state if this is a satisfactory workaround, so feedback
here welcome. I can state that this allows kexec to load/unload/kexec
on Xen and non-Xen environments that I've tested without issue.
With this patch applied, kexec-tools can be built with Xen
support and yet there is no explicit run-time dependency on
libxenctrl.so. Thus it can also be deployed in non-Xen
environments where libxenctrl.so is not installed.
# ldd build/sbin/kexec
linux-vdso.so.1 => (0x00007fff7dbcd000)
liblzma.so.0 => /usr/lib64/liblzma.so.0 (0x00000038d9000000)
libz.so.1 => /lib64/libz.so.1 (0x00000038d6c00000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000038d6400000)
libc.so.6 => /lib64/libc.so.6 (0x00000038d6000000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038d6800000)
/lib64/ld-linux-x86-64.so.2 (0x0000562dc0c14000)
# build/sbin/kexec -v
kexec-tools 2.0.16
This feature/ability is enabled with the following:
./configure --with-xen=dl
The previous --with-xen=no and --with-xen=yes still work as before.
Not specifying a --with-xen still defaults to --with-xen=yes.
As I've introduced a new build and run-time mode, I've done an
extensive matrix of both build-time and run-time checks of kexec
with this patch applied. The set of build-time scenarios are:
1: configure --with-xen=no and Xen support NOT present
2: configure --with-xen=no and Xen support IS present
3: configure --with-xen=yes and Xen support NOT present
4: configure --with-xen=yes and Xen support IS present
5: configure --with-xen=dl and Xen support NOT present
6: configure --with-xen=dl and Xen support IS present
Xen support present requires that configure can find both
xenctrl.h and libxenctrl.so.
Then for each of the six scenarios above, the corresponding kexec
binary was tested on a Xen system (Oracle's OVS dom0) and a
non-Xen system (Oracle Linux).
There are two build-time checks: did kexec build, and did
it contain libxenctrl.so? The presence of libxenctrl.so
in kexec was checked via ldd. The results were:
Scenario | Build | libxenctrl.so | Result
1 | pass | no | pass - see Note 1
2 | pass | no | pass - see Note 1
3 | pass | no | pass - see Note 2
4 | pass | yes | pass - see Note 3
5 | pass | no | pass - see Note 2
6 | pass | no | pass - see Note 4
Note 1: This passes since due to --with-xen=no, there will
be no Xen support in kexec and therefore no libxenctrl.so a
in the kexec.
Note 2: This passes since while --with-xen=yes, the configure
displays a message indicating that Xen support is disabled,
and allows kexec to build (this is the same behavior as prior
to this patch). And since Xen support is disabled, there is
no libxenctrl.so in the kexec.
Note 3: This passes since with --with-xen=yes and configure
locating the xenctrl.h and libxenctrl.so, support for Xen was
built into kexec. Ldd shows an explicit dependency on the library.
Note 4: This passes since with --with-xen=dl and configure
locating the xenctrl.h and libxencrl.so, support for Xen
was built into kexec. However, this uses the new technique
introduced by this patch and, as a result, ldd shows that the
libxenctrl.so is not a explicit run-time dependency for kexec
(rather libdl.so is now an explicit dependency). This is
precisely the goal of this patch!
The net effect is that there are now three "flavors" of a kexec
binary (prior to this patch there were two): a) kexec with no
support for Xen [scenarios 1, 2, 3, 5], b) kexec with support
for Xen and libxenctrl.so as an explicit dependency [scenario 4],
and c) kexec with support for Xen and libxenctrl.so is NOT an
explicit dependency [scenario 6].
The run-time checks are to take each of the six scenarios above
and run the corresponding kexec binary on both a Xen system and
a non-Xen system. The test for each kexec scenario was:
% service kdump stop
% vi /etc/init.d/kdump
change KEXEC= to /sbin/kexec-[123456]
% service kdump start
# If not FAILED, then below
% service kdump status
Kdump is operational
% rm -fr /var/crash/*
% echo c > /proc/sysrq-trigger
# after reboot verify vmcore generated
% ls -al /var/crash/<tab>
The results were:
Scenario | Xen environment | non-Xen environment
1 | fail - see Note 5 | pass
2 | fail - see Note 5 | pass
3 | fail - see Note 6 | pass
4 | pass | fail - see Note 7
5 | fail - see Note 6 | pass
6 | pass | pass
Note 5: Due to --with-xen=no, kexec lacks support for Xen and will
fail in the Xen environment. This behavior is the same as prior
to this patch.
Note 6: Due to the missing xenctrl.h and libxenctrl.so, kexec was
built without support for Xen, and thus will fail in the Xen
environment. This behavior is the same as prior to this patch.
Note 7: This kexec has the explicit dependency on libxenctrl.so
which prevents it from running in a non-Xen environment. This is
expected as this is the original issue for which this patch is
intended to address.
Note that for scenarios 1, 2, 3 and 5 kexec lacks support for Xen,
thus these versions are expected to "fail" in a Xen environment.
On the flip side, since a non-Xen environment does not need
libxenctrl.so, all but scenario 4 are expected to "pass" in a
non-Xen environment. The results match these expectations!
And, of course, importantly with this patch applied, it did not
have an adverse impact on kexec build or run-time.
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>
|
|
get_kernel_stext_sym() has been defined for both arm and i386. Other
architecture might need some other kernel symbol address. Therefore rewrite
this function as generic function to get any kernel symbol address.
More over, kallsyms is not arch specific representation, therefore have
common function for all arches.
Signed-off-by: Pratyush Anand <panand@redhat.com>
[created symbols.c]
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: David Woodhouse <dwmw@amazon.co.uk>
Tested-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
MUSL doesn't support %L except for floating-point arguments; therefore,
%ll must be used instead with integer arguments.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
/proc/kallsyms
Kernel symbol page_offset_base could be unavailable when mm KASLR code is
not compiled in kernel. It's inappropriate to print out error message
when failed to search for page_offset_base from /proc/kallsyms. Seems now
there is not a way to find out if mm KASLR is compiled in or not. An
alternative approach is only printing out debug message in get_kernel_sym
if failed to search a expected kernel symbol.
Do it in this patch, a simple fix.
Signed-off-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
I got below error while tesing kexec -p:
"Can't find kernel text map area from kcore"
The case is the pt_load start addr was same as stext_sym. The checking
code should really be saddr <= stext_sym so that the right pt_load area
includes stext_sym can be matched.
This was not reported by people previously because it will fail over to
use hardcode X86_64__START_KERNEL_map to match the pt_load areas again
in later code and it sometimes succeeds because of kernel address
randomization.
With this change according to my test stext_sym checking can garantee
falling into right pt_load area if we get correct stext_sym.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Multiple changes were made on KASLR (right now in linux-next). One of
them is randomizing the virtual address of the physical mapping, vmalloc
and vmemmap memory sections. It breaks kdump ability to read physical
memory.
This change identifies if KASLR memories randomization is used by
checking if the page_offset_base variable exists. It search for the
correct PAGE_OFFSET value by looking at the loaded memory section and
find the lowest aligned on PUD (the randomization level).
Related commits on linux-next:
- 0483e1fa6e09d4948272680f691dccb1edb9677f: Base for randomization
- 021182e52fe01c1f7b126f97fd6ba048dc4234fd: Enable for PAGE_OFFSET
Signed-off-by: Thomas Garnier <thgarnie@google.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 8a1aa35a1077b42bc2a2afb05d24b637e1edf2a1.
|
|
Crash kernel region size is available via sysfs on Linux running on
bare metal. However, this does not work when Linux runs as Xen dom0.
In this case Xen crash kernel region size should be established using
__HYPERVISOR_kexec_op hypercall (Linux kernel kexec functionality does
not make a lot of sense in Xen dom0). Sadly hypercalls are not easily
accessible using shell scripts or something like that. Potentially we
can check "xl dmesg" output for crashkernel option but this is not nice.
So, let's add this functionality, for Linux running on bare metal and
as Xen dom0, to kexec-tools. This way kdump scripts may establish crash
kernel region size in one way regardless of platform. All burden of
platform detection lies on kexec-tools.
Figure (and unit) displayed by this new kexec-tools functionality is
the same as one taken from /sys/kernel/kexec_crash_size.
This functionality is available on x86 platform only. If idea is acceptable
then I can prepare patches for other platforms (if it is possible and make
sense) and repost them as fully flagged patch series.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec-tools build fails on my laptop with RHEL7.1 installed:
gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include -I./util_lib/include -Iinclude/ -I./kexec/arch/x86_64/include -c -MD -o kexec/arch/i386/kexec-x86-common.o kexec/arch/i386/kexec-x86-common.c
In file included from kexec/arch/i386/kexec-x86-common.c:36:0:
kexec/arch/i386/../../kexec.h:19:2: error: #error BYTE_ORDER not defined
#error BYTE_ORDER not defined
^
kexec/arch/i386/../../kexec.h:23:2: error: #error LITTLE_ENDIAN not defined
#error LITTLE_ENDIAN not defined
^
kexec/arch/i386/../../kexec.h:27:2: error: #error BIG_ENDIAN not defined
#error BIG_ENDIAN not defined
^
In file included from kexec/arch/i386/kexec-x86-common.c:37:0:
kexec/arch/i386/../../kexec-syscall.h: In function ‘kexec_load’:
kexec/arch/i386/../../kexec-syscall.h:74:2: warning: implicit declaration of function ‘syscall’ [-Wimplicit-function-declaration]
return (long) syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
^
make: *** [kexec/arch/i386/kexec-x86-common.o] Error 1
The build error was introduced by below commit:
commit c9c21cc107dcc9b6053e39ead1069e03717513f9
Author: Baoquan He <bhe@redhat.com>
Date: Thu Aug 6 19:10:55 2015 +0800
kexec: use _DEFAULT_SOURCE instead to remove compiling warning
Now compiling will print warning like below. Change code as it suggested.
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
^
See manpage: http://man7.org/linux/man-pages/man7/feature_test_macros.7.html
_BSD_SOURCE has been deprecated since glibc 2.20, To allow code that requires
_BSD_SOURCE in glibc 2.19 and earlier and _DEFAULT_SOURCE in glibc 2.20 and
later to compile without warnings, define both _BSD_SOURCE and _DEFAULT_SOURCE.
Thus fix it by adding back _BSD_SOURCE along with _DEFAULT_SOURCE.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There may be more than one crash kernel regions on x86. Currently,
kexec-tools picks the largest one. If high reservation is smaller
than low, it will try to load panic kernel low. However, the kexec
syscall checks that target address is within crashk_res boundaries,
so attempts to load crash kernel low result in -EADDRNOTAVAIL, and
kexec prints out this error message:
kexec_load failed: Cannot assign requested address
Looking at the logic in arch/x86/kernel/setup.c, there are only two
possible layouts:
1. crashk_res is below 4G, and there is only one region,
2. crashk_res is above 4G, and crashk_low_res is below 4G
In either case, kexec-tools must pick the highest region.
Changelog:
* v3: rename function to get_crash_kernel_load_range
* v2: remove unnecessary local variables
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Kernel add E820_PRAM or E820_PMEM type for NVDIMM memory device.
Now support them in kexec too.
Reported-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Now compiling will print warning like below. Change code as it suggested.
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
^
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Commit 4362bfac changes params for kexec_iomem_for_each_line from
'unsigned long' to 'unsigned long long'.
This patch fixes forgotten changes for sh and x86 archs.
Bug causes incorrect parsing of memory ranges.
Signed-off-by: Roman Pen <r.peniaev@gmail.com>
Cc: kexec@lists.infradead.org
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If kernel does not export efi runtime maps it means 1:1 mapping does not
work or user explictly boot with efi=old_map. In this case efi setup code
will failback to noefi boot, but for kdump case we still need pass extra
acpi_rsdp cmdline.
Thus adding a check in kdump path.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For kernel boot with efi=old_map or some quirked machines like SGI UV
they use old ioremap instead of 1:1 mapping. But kexec efi support
depends on the 1:1 mapping thus we need to switch to use the old way
There's a kernel patch for exporting the efi flags so we can check the memory
mapping method. But user may want to explictly disable efi boot for unknown
reasons.
So here add a new arch option '--noefi' for this case.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In kdump path, now we store all the 2nd kernel memory ranges in
memmap_p. We could use just cmdline_add_memmap() to add all types of
memory ranges to 2nd kernel cmdline.
So clean up here, merge cmdline_add_memmap_acpi() into
cmdline_add_memmap().
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
This reverts commit e35aa29fb40b37bf86d980b2e19af5e01c2d2549.
This patch is based on the commit 49320340f705694e387d794f7f19d407ad9baefa
"kexec: lengthen the kernel command line image"
Since the latter commit has been reverted due to its useless, this
patch should be reverted too.
Besides, This patch also changed a kernel restriction of max segments
from 16 to 70. Though kexec-tools could have more segments, more than 16,
the kexec_load syscall will still fail for the kernel side has a restriction
of 16.
Cc: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Vivek found specical handling crashkernel low in not good.
We should extend kexec-tools to handle multiple Crash kernel instead.
Extend crash_reserved_mem to array instead and use
kexec_iomem_for_each_line directly. After that we can drop
crashkernel low.
-v2: fix left over calling of parse_iomem_single() found by Vivek.
Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Functions:
- cmdline_add_memmap()
- cmdline_add_memmap_acpi()
- cmdline_add_memmap_reserved()
is kind of similar, So add a new function cmdline_add_memmap_internal() to
hold the common codes, reducing the duplication.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be more clear.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
I got the following warnings when I compiled kexec-tools:
kexec/kexec-elf-rel.c: In function 'elf_rel_load':
kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 6 has type 'unsigned int'
kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 7 has type 'long long unsigned int'
kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'long long unsigned int'
kexec/arch/i386/crashdump-x86.c: In function 'get_kernel_paddr':
kexec/arch/i386/crashdump-x86.c:99: warning: format '%016Lx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t'
kexec/arch/i386/crashdump-x86.c: In function 'get_kernel_vaddr_and_size':
kexec/arch/i386/crashdump-x86.c:171: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int'
kexec/arch/i386/crashdump-x86.c: In function 'get_crash_notes':
kexec/arch/i386/crashdump-x86.c:781: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t'
kexec/arch/i386/crashdump-x86.c: In function 'load_crashdump_segments':
kexec/arch/i386/crashdump-x86.c:905: warning: 'nr_ranges' may be used uninitialized in this function
The patch fix above warnings.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The crash kernel is not able to find its root device if that device is not
on PCI 0.
This is because it is booted with the command line option memmap=exactmap
which currently clears the e820 table and does not restore reserved spaces.
This works for a device on PCI 0 because ACPI falls back to a legacy mode.
But the error message " [Firmware Bug]: PCI: MMCONFIG at
[mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources"
is written to the log even in this functioning case.
It fails for some devices on UV2, and only for UV2, because SGI seems to
be the only manufacturer currently using the extended PCI(>0).
The fix is simple, as long as the command line is long enough to include
all the reserved spaces.
The command line may have to be lengthened. See
[PATCH] kexec: lengthen the kernel command line image
Signed-off-by: Cliff Wickman <cpw@sgi.com>
[ horms@verge.net.au: Manually applied due to conflicts ]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For the allocation, using CRASH_MAX_MEMMAP_NR instead of KEXEC_MAX_SEGMENTS + 1
seems more understandable.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
[horms@verge.net.au: Applied by hand due to conflict]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kernel could have that in /proc/iomem, will use it for kdump kernel
for dma32
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve
the acpi root table physical address.
Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab
If there's no such file or read fail the function will just do nothing.
Tested efi boot Fedora 17 on thinkpad T420.
Some background info for this issue:
http://lists.infradead.org/pipermail/kexec/2010-March/003889.html
[v1 -> v2]:
Address comments from Khalid and Simon
use fgets instead of read(2) to iterate the file
do not add 'noefi' because kexec does not construct EFI signature
in bootloader signature in boot_params, so kexec'd kernel will
disable EFI automatically even without noefi.
Signed-off-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Khalid Aziz <khalid@gonehiking.org>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
get_crash_memory_ranges() is unreliable under Xen. Proper machine
memory map could be obtained under Xen by calling __HYPERVISOR_memory_op
hypercall with XENMEM_machine_memory_map argument. get_crash_memory_ranges_xen()
does that. It is implemented using ioctl() or libxenctrl interface.
This solution is compatible with 3.x and 4.x Xen versions.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Move crash memory ranges logging from get_crash_memory_ranges()
to load_crashdump_segments(). This solution will be used by
fixed Xen kdump support, too.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Get backup area start address and size directly from mem_range.
Under Xen /proc/iomem contains invalid values.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Extract code segregating lowmem region and move it to new
segregate_lowmem_region(). This function will be used by
fixed Xen kdump support, too.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
is_crashkernel_mem_reserved()
Move crash kernel area placement and size detection
from get_crash_memory_ranges() to is_crashkernel_mem_reserved().
Former one will not be used by fixed Xen kdump support.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec-tools package for debian includes a patch that adds a more
descriptive error message when someone tries to laod a crash kernel
and didn't remember to boot up with crashkernel= parameter. This
patch would be of general interest. This patch was originally written
by Alastair McKinstry.
Please apply.
Signed-off-by: Khalid Aziz <khalid.aziz@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently the debugging code is under #ifdef DEBUG, which
means when we want to debug, we have to re-compile the source
code with -DDEBUG. This is not convenient, we want to have
a generic --debug option so that we can enable debugging code
without re-compiling.
This patch moves the arch-specific --debug to generic place
and moves code under #ifdef DEBUG to --debug on x86.
BTW, the size of kexec binary increases very little after this patch.
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
a) We don't need 'crash_notes' array at all, save some bytes on stack.
b) We forgot to fclose 'fp' before return.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
