Re: [Xen-devel] [PATCH v2] x86/boot: Fix the boot time relocation calculations

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.06.17 at 12:45, <andrew.cooper3@xxxxxxxxxx> 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 recent
> versions of Grub do fill this in appropriately, tboot does not.  (In fact,
> tboot loads Xen at the preferred address, but claims a load address of 8M.)
> 
> 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 the
> 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 under
> 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 stack
> 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 entered.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Tested-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel