Re: [Xen-devel] [PATCH] docs/sphinx: How Xen Boots on x86

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.12.2019 17:42, Andrew Cooper wrote:
> On 09/12/2019 15:20, Jan Beulich wrote:
>> On 06.12.2019 20:34, Andrew Cooper wrote:
>>> +Objects
>>> +~~~~~~~
>>> +
>>> +To begin with, most object files are compiled and linked.  This includes 
>>> the
>>> +Multiboot 1 and 2 headers and entrypoints, including the Multiboot 2 tags 
>>> for
>>> +EFI extensions.  When ``CONFIG_PVH_GUEST`` is selected at build time, this
>>> +includes the PVH entrypoint and associated ELF notes.
>>> +
>>> +Depending on whether the compiler supports ``__attribute__((__ms_abi__))`` 
>>> or
>>> +not, either an EFI stub is included which nops/fails applicable setup 
>>> calls,
>>> +or full EFI support is included.
>> Perhaps also mention that the linker needs to support the necessary
>> binary output format? And perhaps "setup and runtime calls"?
> 
> Link time behaviour is (deliberately) in a later section.

I realize(d) this, but the statement above is simply not true without
also mentioning required linker capabilities: The object files won't
have "full EFI support included" in this case. So I'd expect a "see
also" here at the very least.

>>> +Protocols and entrypoints
>>> +~~~~~~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +All headers and tags are built in ``xen/arch/x86/boot/head.S``
>>> +
>>> +The Multiboot 1 headers request aligned modules and memory information.  
>>> Entry
>>> +is via the start of the binary image, which is the ``start`` symbol.  This
>>> +entrypoint must be started in 32bit mode.
>>> +
>>> +The Multiboot 2 headers are more flexible, and in addition request that the
>>> +image be loaded as high as possible below the 4G boundary, with 2M 
>>> alignment.
>>> +Entry is still via the ``start`` symbol as with MB1.
>> Perhaps explicitly (re)state this is in 32-bit mode?
>>
>>> +Headers for the EFI MB2 extensions are also present.  These request that
>>> +``ExitBootServices()`` not be called, and register ``__efi_mb2_start`` as 
>>> an
>>> +alternative entrypoint, entered in 64bit mode.
>>> +
>>> +If ``CONFIG_PVH_GUEST`` was selected at build time, an Elf note is included
>>> +which indicates the ability to use the PVH boot protocol, and registers
>>> +``__pvh_start`` as the entrypoint, entered in 32bit mode.
>>> +
>>> +
>>> +xen.gz
>>> +~~~~~~
>>> +
>>> +The objects are linked together to form ``xen-syms`` which is an ELF64
>>> +executable with full debugging symbols.  ``xen.gz`` is formed by stripping
>>> +``xen-syms``, then repackaging the result as an ELF32 object with a single
>>> +load section at 2MB, and ``gzip``-ing the result.  Despite the ELF32 
>>> having a
>>> +fixed load address, its contents are relocatable.
>> This is a little ambiguous I guess - most of the code is PIC and as
>> such relocatable, but not in a way a boot loader could arrange for.
> 
> I don't follow your concern.
> 
> Everything which needs to be is position independent (subject to being
> loaded on a 2M boundary IIRC), and this property is requested by the MB2
> header.

Oh, sorry, it had been too many years of sym_phys() before it became
sym_offs(). You're right.

>>> +Any bootloader which unzips the binary and follows the ELF headers will 
>>> place
>>> +it at the 2M boundary and jump to ``start`` which is the identified entry
>>> +point.  However, Xen depends on being entered with the MB1 or MB2 
>>> protocols,
>>> +and will terminate otherwise.
>>> +
>>> +The MB2+EFI entrypoint depends on being entered with the MB2 protocol, and
>>> +will terminate if the entry protocol is wrong, or if EFI details aren't
>>> +provided, or if EFI Boot Services are not available.
>>> +
>>> +
>>> +xen.efi
>>> +~~~~~~~
>>> +
>>> +When a PEI-capable toolchain is found, the objects are linked together and 
>>> a
>>> +PE64 binary is created.  It can be run directly from the EFI shell, and has
>> I think it's commonly called PE32+, not PE64.
> 
> Ok., because by definition, it can stack.

How does stacking come into play here?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel