Xen kexec status

David Woodhouse dwmw2 at infradead.org
Fri Apr 26 23:15:52 PDT 2019


I've been looking at kexec into Xen, and from Xen.

Kexec-tools doesn't support Multiboot v2, and doesn't treat the Xen
image as relocatable. So it loads it at address zero, which causes lots
of amusement:

Firstly, head.S trusts the low memory limit found in the BDA, which has
been scribbled on. Hacking around that and setting no-real-mode does
make kexec into Xen from Linux work.

Secondly, kexec (in xen_kexec_load()) adds a mapping of the 0-1MiB
region, which "overlaps" with where Xen is actually loaded, so *Xen*
refuses the kexec_load hypercall.

For kexec from Xen I also reverted to kexec-tools 2.0.16 as commit
894bea9335f57b62c ("kexec-tools: Perform run-time linking of
libxenctrl.so") seems to have broken things by not always defining
HAVE_LIBXENCTRL when it should. I'll fix that shortly.

Most of the above is relatively simply worked around by hacking the Xen
image to be ET_DYN (so that kexec will relocate it) and then using
kexec --mem-min=0x100000. I'll probably implement Multiboot v2 support
in kexec-tools to allow for saner relocation.

We should fix head.S. One option is to recognise when the load address
is zero, and automatically eschew the BDA and trigger the no-real-mode
behaviour when that is the case. Better suggestions welcome.

Should we also avoid having a load segment at offset zero in the image,
so that it doesn't scribble on the BDA by default?

Should we also fix Xen's kexec_load not to refuse overlapping segments
if they are not loaded (bufsz==0)? I'm not quite sure what's going on
there; doesn't this happen with paging disabled anyway, so why would we
need an explicit mapping of RAM?

After that, I'm looking at using Xen as a crash kernel, which means I
really don't want it scribbling on low memory that it hasn't been
explicitly told it can use. First attempt at this is at 
http://david.woodhou.se/0001-x86-boot-Use-trampoline_protmode_entry-in-place.patch
but as noted there, it only works for a single processor for now; I'll
fix it as described therein.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5174 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20190427/afa82033/attachment.bin>


More information about the kexec mailing list