summaryrefslogtreecommitdiff
path: root/kexec/kexec-xen.c
AgeCommit message (Collapse)Author
2022-03-23kexec-xen: Allow xen_kexec_exec() to return in case of Live UpdateRaphael Ning
Currently, my_exec() does not expect the Xen KEXEC_CMD_kexec hypercall to return on success, because it assumes that the hypercall always triggers an immediate reboot. However, for Live Update, the hypercall merely schedules the kexec operation and returns; the actual reboot happens asynchronously. [1] Therefore, rework the Xen code path of my_exec() such that it does not treat a successfully processed Live Update request as an error. Also, rephrase the comment above the function to remove ambiguity. [1] https://lists.xen.org/archives/html/xen-devel/2021-05/msg00286.html Signed-off-by: Raphael Ning <raphning@amazon.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02kexec-xen: Use correct image type for Live UpdateRaphael Ning
Unlike xen_kexec_load(), xen_kexec_unload() and xen_kexec_status() fail to distinguish between normal kexec and Xen Live Update image types. Fix that by introducing a new helper function that maps internal flags to KEXEC_TYPE_*, and using it throughout kexec-xen.c. Signed-off-by: Raphael Ning <raphning@amazon.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-04-07kexec-xen: Introduce --exec-live-update to trigger a live updateVarad Gautam
This signals xen to do a KEXEC_TYPE_LIVE_UPDATE kexec operation. Signed-off-by: Varad Gautam <vrd@amazon.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-04-07kexec: Introduce --load-live-update for xenVarad Gautam
Support loading a live update image for xen from kexec userspace. For a multiboot2 Elf on a xen setup, this will: - load the Elf into KEXEC_RANGE_MA_XEN - load purgatory and modules into KEXEC_RANGE_MA_LIVEUPDATE - append the Elf cmdline with " liveupdate=<size>@<addr> v2: define xen related symbols outside of HAVE_LIBXENCTRL Signed-off-by: Varad Gautam <vrd@amazon.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-04-07kexec-xen: Introduce xen_get_kexec_range to wrap xc_kexec_get_rangeVarad Gautam
And convert all callers of xc_kexec_get_range to use this. Allows reusing sanity checks for other KEXEC_RANGEs v2: define xen_get_kexec_range outside of HAVE_LIBXENCTRL Signed-off-by: Varad Gautam <vrd@amazon.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-15xen: Avoid overlapping segments in low memoryDavid Woodhouse
Unlike Linux which creates a full identity mapping, Xen only maps those segments which are explicitly requested. Therefore, xen_kexec_load() silently adds in a segment from zero to 1MiB to ensure that VGA memory and other things are accessible. However, this doesn't work when there are already segments to be loaded under 1MiB, because the overlap causes Xen to reject the kexec_load. Be more careful and just infill the ranges which are required instead of naïvely adding a full 0-1MiB segment at the end of the list. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> 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>
2018-01-24kexec-tools: Call dlclose() from within __xc_interface_close()Eric DeVolder
This patch is a follow-on to commit 43d3932e "kexec-tools: Perform run-time linking of libxenctrl.so". This patch addresses feedback from Daniel Kiper. In the original patch, the call to dlclose() was omitted, in contrast to the description in the commit message. This patch inserts the call. Note that this dynamic linking feature is dependent upon the proper operation of the RTLD_NODELETE flag to dlopen(), which does work as advertised on Linux (otherwise the call to dlclose() should be omitted). 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>
2018-01-24kexec-tools: Perform run-time linking of libxenctrl.soEric DeVolder
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>
2017-01-26kexec: implemented XEN KEXEC STATUS to determine if an image is loadedEric DeVolder
Instead of the scripts having to poke at various fields we can provide that functionality via the -S parameter. kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash state. It does not say anything about Xen kexec/crash state. So, we need a special approach to get the latter. Though for compatibility we provide similar functionality in kexec-tools for the former. This change enables the --status or -S option to work either with or without Xen. Returns 0 if the payload is loaded. Can be used in combination with -l or -p to get the state of the proper kexec image. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-12-03kexec/xen: Fix typo in __i386__ preprocessor identifierAndrew Cooper
This typo was introduced in c/s c0b4a3f95dd80256cc6d7084436235e69b4933fb It prevents a 32bit build of kexec from loading a 32bit crash image. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-12-03kexec-tools/xen: Remove redundant includeDaniel Kiper
Remove redundant include of stdlib.h introduced by commit d01680c28ba7bf1e02f74aa5841247a45738f5d4 (kexec/xen: Correct some compile errors). Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-11-19kexec/xen: Correct some compile errorsSimon Horman
Correct various problems introduced by 08cf823704b0fa3b ("kexec/xen: directly load images images into Xen"). These all relate to the case here HAVE_LIBXENCTRL is not set. 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>