|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] docs/sphinx: How Xen Boots on x86
On 10/12/2019 07:52, Jan Beulich wrote: > 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. Note how XEN_BUILD_EFI and XEN_BUILD_PE are different, one by compiler support for ms_abi, and one by linker support for i386pep. Linker support for i386pep is not required at all to get EFI support in Xen. This is how the MB2+EFI path is constructed. > >>>> +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. Yeah - it was fixed in the MB1 days, but this is no longer the case. > >>>> +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? Mis-paste on my behalf (that text was an early version discussing chainloading). That should have ended at ok. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |