diff options
| author | Jan Beulich <jbeulich@novell.com> | 2011-06-28 09:19:35 +0100 |
|---|---|---|
| committer | Jan Beulich <jbeulich@novell.com> | 2011-06-28 09:19:35 +0100 |
| commit | bf6501a62e80ec1cf756290d4c3ec4991455f64e (patch) | |
| tree | fdd62100f57c6cd816e1f7cef369ced44f991027 /xen/arch/x86/boot | |
| parent | f402de45cd8b93cc41fff6f0666b1cdd3d765909 (diff) | |
| download | xen-bf6501a62e80ec1cf756290d4c3ec4991455f64e.tar.gz xen-bf6501a62e80ec1cf756290d4c3ec4991455f64e.tar.bz2 xen-bf6501a62e80ec1cf756290d4c3ec4991455f64e.zip | |
x86-64: EFI boot code
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@novell.com>
Diffstat (limited to 'xen/arch/x86/boot')
| -rw-r--r-- | xen/arch/x86/boot/trampoline.S | 1 | ||||
| -rw-r--r-- | xen/arch/x86/boot/x86_64.S | 2 |
2 files changed, 3 insertions, 0 deletions
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S index ad15f5c4e8..e5b4dbef45 100644 --- a/xen/arch/x86/boot/trampoline.S +++ b/xen/arch/x86/boot/trampoline.S @@ -38,6 +38,7 @@ trampoline_gdt: .long 0x0000ffff | ((BOOT_TRAMPOLINE & 0x00ffff) << 16) .long 0x00009200 | ((BOOT_TRAMPOLINE & 0xff0000) >> 16) + .globl cpuid_ext_features cpuid_ext_features: .long 0 diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S index edf7891610..3c0958bcf2 100644 --- a/xen/arch/x86/boot/x86_64.S +++ b/xen/arch/x86/boot/x86_64.S @@ -84,11 +84,13 @@ multiboot_ptr: .long 0 .word 0 + .globl gdt_descr gdt_descr: .word LAST_RESERVED_GDT_BYTE .quad boot_cpu_gdt_table - FIRST_RESERVED_GDT_BYTE .word 0,0,0 + .globl idt_descr idt_descr: .word 256*16-1 .quad idt_table |