[Xen-devel] Xen kexec status

David Woodhouse dwmw2 at infradead.org
Sat Apr 27 03:54:23 PDT 2019

On Sat, 2019-04-27 at 08:15 +0200, David Woodhouse wrote:
> 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?

Oh, and then there's this...

[dwmw2 at localhost kexec-tools]$ sudo mv /dev/xen/hypercall /dev/xen/nothypercall
[dwmw2 at localhost kexec-tools]$ sudo ./build/sbin/kexec -l /root/xen  --mem-min=0x200000
[dwmw2 at localhost kexec-tools]$ sudo mv /dev/xen/nothypercall /dev/xen/hypercall
[dwmw2 at localhost kexec-tools]$ sudo ./build/sbin/kexec -l /root/xen  --mem-min=0x200000
xencall: error: alloc_pages: mmap failed: Invalid argument

openat(AT_FDCWD, "/dev/xen/privcmd", O_RDWR|O_CLOEXEC) = 4
openat(AT_FDCWD, "/dev/xen/hypercall", O_RDWR|O_CLOEXEC) = 5
openat(AT_FDCWD, "/dev/xen/privcmd", O_RDWR|O_CLOEXEC) = 6
openat(AT_FDCWD, "/dev/xen/privcmd", O_RDWR|O_CLOEXEC) = 7
openat(AT_FDCWD, "/dev/xen/hypercall", O_RDWR|O_CLOEXEC) = 8
openat(AT_FDCWD, "/dev/xen/privcmd", O_RDWR|O_CLOEXEC) = 9
ioctl(9, _IOC(_IOC_NONE, 0x50, 0x5, 0x10), 0x7ffe34ea3650) = 0
mmap(NULL, 2641920, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0) = -1 EINVAL (Invalid argument)
write(2, "xencall: ", 9xencall: )                = 9
write(2, "error: ", 7error: )                  = 7
write(2, "alloc_pages: mmap failed", 24alloc_pages: mmap failed) = 24
write(2, ": Invalid argument", 18: Invalid argument)      = 18
-------------- 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/b4914721/attachment.bin>

More information about the kexec mailing list