]> xenbits.xensource.com Git - people/iwj/xen.git/commit
x86/setup: do not relocate Xen over current Xen image placement
authorDaniel Kiper <daniel.kiper@oracle.com>
Tue, 23 Jan 2018 09:42:10 +0000 (10:42 +0100)
committerJan Beulich <jbeulich@suse.com>
Tue, 23 Jan 2018 09:42:10 +0000 (10:42 +0100)
commit0d31d16808689f88681450868d9512d332deb75d
tree01b2035e70ed0caf73dc8f376b6037dd18b5b99b
parenta5e7ce9560b408dbdc2f7fb8a58f6209601cc054
x86/setup: do not relocate Xen over current Xen image placement

Otherwise, due to Xen code/data changes under CPU feet, Xen may crash
silently at boot.

We were hit by the issue in OVS Xen 4.4 with my earlier version of
EFI/Multiboot2 patches. Initially its implementation allowed relocation
of Xen even if it was relocated by the bootloader. This led to the
crashes on some new Oracle machines because copy destination partially
overlapped with the end of current/initial Xen image placement.

After some discussion on Xen-devel we decided to disable Xen relocation in
my EFI/Multiboot2 upstream patches if the booloader did the work for us.
Though one case is still not covered. If Xen is not relocated by the
booloader then it tries to do that by itself. If all RAM regions above
currently occupied one are unsuitable for relocation then Xen tries to move
itself higher in it. And if (end - reloc_size + XEN_IMG_OFFSET) goes below
__pa(_end) then copy/relocation destination overlaps, at least partially,
with its source.

I can agree that this should not happen on todays machines very often.
If at all. It is rather unusual to not have usable RAM regions above
~5 MiB nowadays. Though I think that we should at least consider putting
such safety measure here. Otherwise Xen may crash mysteriously without
any stack trace. It is very confusing and impairs further debugging.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
xen/arch/x86/setup.c