| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
It retains IA64-specific bits in code imported from elsewhere (e.g.
ACPI, EFI) as well as in the public headers.
It also doesn't touch the tools, mini-os, and unmodified_drivers
sub-trees.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
| |
This addresses all remaining build problems introduced over the last
several months.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
|
| |
It's not clear this is needed - Linux doesn't use the MPS table even
if available, and no system having one was seen so far.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows Dom0 access to all suitable EFI runtime services. The
actual calls into EFI are done in "physical" mode, as entering virtual
mode has been determined to be incompatible with kexec (EFI's
SetVirtualAddressMap() can be called only once, and hence the
secondary kernel can't establish its mappings). ("Physical" mode here
being quoted because this is a mode with paging enabled [otherwise
64-bit mode wouldn't work] but all mappings being 1:1.)
Open issue (not preventing this from being committed imo):
Page (and perhaps other) faults occuring while calling runtime
functions in the context of a hypercall don't get handled correctly
(they don't even seem to reach do_page_fault()). I'm intending to
investigate this further.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
|
|
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>
|
