| 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>
|
|
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>
|
|
It appears that (older?) revisions of xenctl.h define
all of the E820_* values used in kexec-x86-common.c except
E820_PMAM and E820_PMEM. This results in a build failure when
building against libxenctl.
Avoid this problem by providing local definitions of those values.
It seems reasonable to do so in the kexec-x86-common.c as
currently that is the only source file that uses the values in question.
Fixes: 56a12abc1df1 ("kexec: fix mmap return code handling")
Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Petr Tesarik <ptesarik@suse.com>
Cc: Baoquan He <bhe@redhat.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>
|
|
gcc 4.9.1 tells me this variable is set but unused
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
[ horms@verge.net.au: Applied manually due to conflict ]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Rename e820_to_kexec_type() to xen_e820_to_kexec_type() and export it.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
get_memory_ranges_sysfs() and get_memory_ranges_proc_iomem()
are 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_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 <dkiper@net-space.pl>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Rename fixup_memory_ranges_sysfs() to fixup_memory_ranges().
It is generic function and it could be used to fixup memory
ranges from other sources than sysfs (e.g. Xen).
Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch changes the behavior of the kexec loader when the
"add_efi_memmap" option is present on the currently running kernel's
command line, to read the kernel memory map from /proc/iomem instead
of /sys/firmware/memmap.
On EFI systems, sometimes the e820 table is missing or incomplete.
Systems like these use the "add_efi_memmap" option to add EFI's memory
table entries to the kernel's memory table to build a complete picture
of the system's memory; however, using the option does not add these
entries to the table used to populate /sys/firmware/memmap, which is
meant to be a pristine original copy.
The kexec loader uses the pristine memory map by default, which causes
problems when the loader doesn't have a complete picture of the system
and incorrectly loads the kernel or ramdisk in places that aren't
actually usable. This change makes the kexec loader check the running
kernel's command line for the "add_efi_memmap" option and if it finds
it, will use the modified map instead of the original map.
signed-off-by: Benjamin Romer <benjamin.romer@unisys.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The memory ranges derived from /sys/firmware/memmap may overlap, causing
the kexec command to fail to load the crash kernel. The typical failure
reports 'Overlapping memory segments at 0x...'.
The preferred remedy might be to fix the BIOS or the kernel, but given
that they may at times generate overlaps, a check in the kexec command
will prevent crash dumps from being effectively disabled.
Diffed against git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes:
kexec/arch/i386/kexec-x86-common.c: In function ‘get_memory_ranges’:
kexec/arch/i386/kexec-x86-common.c:189: \
warning: passing argument 2 of ‘parse_iomem_single’ from incompatible pointer type
kexec/arch/i386/kexec-x86-common.c:189: \
warning: passing argument 3 of ‘parse_iomem_single’ from incompatible pointer type
Yes, that was my own code. :-(
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On Xen, we have to use /proc/iomem to retrieve the memory area for the kexec'd
kernel, not /sys/firmware/memmap. Dom0 kernel gets a E820 map that contains
only one region:
0000000000000000-0000000018e5e000 (System RAM)
Compared to the /proc/iomem:
00000000-0009cbff : System RAM
0009cc00-0009ffff : reserved
000ce000-000d3fff : reserved
000e0000-000fffff : reserved
00100000-1fd6ffff : System RAM
01000000-04ffffff : Crash kernel
1ec00000-1fbfffff : Hypervisor code and data
1f0b4680-1f0b4873 : Crash note
1f0b4900-1f0b4a93 : Crash note
1f0b4b80-1f0b4d13 : Crash note
1f0b4e00-1f0b4f93 : Crash note
...
Without that patch, /proc/vmcore is empty in the kexec'd kernel and I'm unable
to copy the crashdump.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
To support memory backup/restore an option named
--load-preserve-context is added to kexec. When it is specified
toggether with --mem-max, most segments for crash dump support are
loaded, and the memory range between mem_min to mem_max which has no
segments loaded are loaded as backup segments. To support jump back
from kexeced, options named --load-jump-back-helper and --entry are
added to load a helper image with specified entry to jump back.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Because the get_memory_ranges() function was the same on i386 and x86_64, and
because that /sys/firmware/memmap interface should also be used for x86_64
without *new* code duplication, that part was moved out in a new file called
kexec-x86-common.c. That file only contains the memory map parsing for both the
"old" /proc/iomem interface and the new /sys/firmware/memmap interface.
That file is now built for i386 and x86_64.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
