|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] Elf loader fixes
I'm afraid this won't work for 64-bits, because of the way the vsyscall page
gets set up there. If you dump the program
headers you'll see that the respective segment is at an address close to the
top of the address space, which would make
the image appear to need nearly 2 Gb of memory (making the load fail if there's
less than that available to the
domain).
Also, I'm unclear why you need to make persistent the physical address
information for the dom0 case, and hence why the
bug compatibility hack is needed there.
Jan
>>> Gerd Hoffmann <kraxel@xxxxxxx> 22.02.06 12:37:26 >>>
Hi folks,
The Xen ELF kernel loader is quite quirky wrt. physical and virtual
addresses, probably for historical reasons, linux got that wrong too
until very recently (kexec merge in 2.6.14 or so). The patch below
fixes that.
Changes:
* Fix linux kernel ELF entry point (also submitted to lkml)
* Drop LOAD_OFFSET re-#define hack in xen headers.
* Fix both dom0 and libxc elf loaders.
* add quick mode so loading old linux kernels doesn't break.
Linux-wise everything should be OK with that, but it might break other
OS'es which also use the ELF loader (in case they create bug-compatible
ELF headers with broken paddr entries ...).
please apply,
Gerd
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|