[Xen-devel] [PATCH 2/4] x86-64: EFI boot code

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

Besides introducing the relevant code paralleling parts of what is
under xen/arch/x86/boot/, this adjusts the build logic so that with a
single compilation two images (gzip-compressed ELF and EFI application)
can get created. The EFI part of this depends on a new enough compiler
(supposedly gcc 4.4.x and above, but so far only tested to work with
4.5.x) and a properly configured linker (must support the i386pep
emulation). If either functionality is found to not be available, the
EFI part of the build will simply be skipped.

The patch adds all code to allow Xen and the (accordingly enabled)
Dom0  kernel to boot, but doesn't allow Dom0 to make use of EFI
runtime calls (this will be the subject of the next patch).

Parts of the code were lifted from an earlier never published OS
project of ours - whether respective license information needs to be
added to the respective source file is unclear to me (I was told
internally that adding a GPLv2 license header can be done if needed by
the community).

Open issues (not preventing this from being committed imo):

The trampoline allocation and initialization isn't really nice. This
is due to the trampoline needing to be placed at a fixed address, and
hence making the trampoline relocatable would seem desirable here (as
well as for BIOS-based booting, where the trampoline location needed
to be adjusted a number of time already in the past, due to it
colliding with firmware data).
By excluding mem.S, edd.S, and video.S from copied trampoline (i.e.
moving up wakeup.S? and making sure none of the symbols are used from
EFI code), the effective trampoline size could at least be reduced.

Should the mappings of [__XEN_VIRT_START, mbi.mem_upper) and
[_end, __XEN_VIRT_START+BOOTSTRAP_MAP_BASE) be destroyed, despite
non-EFI code also keeping them?

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>

Attachment: x86-EFI.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel