[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen kexec status
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 Attachment:
smime.p7s _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |