On 14/06/17 11:33, Julien Grall wrote:
Hi Andrew,

On 06/12/2017 11:45 AM, Andrew Cooper wrote:
c/s b28044226e1 "x86: make Xen early boot code relocatable" introduces

     mov $sym_offs(__image_base__),%esi

to the legacy boot path.  However, this is by definition 0, which
means the
boot code only functions correctly when Xen is loaded at its preferred
physical address (2M at the time of writing).

Xen does cope if loaded at an alternative physical address, if the
MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR tag is filled in properly.  While
versions of Grub do fill this in appropriately, tboot does not.  (In
tboot loads Xen at the preferred address, but claims a load address of

Both Multiboot 1 and 2 specify the execution environment as being
flat.  As a
result, Xen needs no help calculating the proper load address.

However, Multiboot specifies %esp as undefined.  Experimentally, using
entry %esp is fine, but this is certainly no guarantee.  Use a
temporary stack
in the first page of RAM, which is one of the safest areas to clobber.

Calculate the load address from %eip alone, and ignore
MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR entirely.  This fixes legacy boot
various versions of tboot.

Finally, set up the stack as soon as possible, which means the BIOS
path has a
usable stack for the entirety of its duration.  Use the full available
size, rather than limiting to an arbitrary 1k.  One side effect is
that the
MB2/EFI path continues to use the EFI stack until the trampoline is

Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Tested-by: Sergey Dyasli <sergey.dya...@citrix.com>
CC: Jan Beulich <jbeul...@suse.com>
CC: Julien Grall <julien.gr...@arm.com>
CC: Daniel Kiper <daniel.ki...@oracle.com>
CC: Doug Goldstein <car...@cardoe.com>
CC: Sergey Dyasli <sergey.dya...@citrix.com>

This is a regression introduced in Xen 4.9, and should therefore be

This is touching early-boot code. I would like to wait a least a push
with this patch on staging before suggesting to push in Xen 4.9.

Release-acked-by: Julien Grall <julien.gr...@arm.com>


Julien Grall

Xen-devel mailing list

Reply via email to