On 27/04/2019 11:54, David Woodhouse wrote:
> 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@localhost kexec-tools]$ sudo mv /dev/xen/hypercall
> /dev/xen/nothypercall
> [dwmw2@localhost kexec-tools]$ sudo ./build/sbin/kexec -l /root/xen
> --mem-min=0x200000
> [dwmw2@localhost kexec-tools]$ sudo mv /dev/xen/nothypercall
> /dev/xen/hypercall
> [dwmw2@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
/dev/xen/hypercall was introduced in 4.17 and this restriction was
lifted in 4.19 by c/s 3941552aec1e04d63999988a057ae09a1c56ebeb which was
tagged for stable.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
