| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
| |
Also clean up some cases of misused/opencoded ENTRY()
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Recent Linux tries to make use of this, and has no way of getting at
these bits without Xen assisting it.
There doesn't appear to be a way to obtain the same information from
UEFI.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We recently saw a machine that has the EBDA extending as low as
0x7c000, so that Xen fails to boot after relocating the trampoline.
To fix this, I removed BOOT_TRAMPOLINE and bootsym_phys completely.
Here are the parts:
1) the trampoline segment is set to 64k below the EBDA. head.S grows
the ability to relocate the trampoline segment
2) reloc.c is made position-independent. It allocates data below the
trampoline, whose address is passed in _eax.
3) cmdline.S is called before relocating, so all bootsym_phys there
become sym_phys.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
jb: - fall back to low memory size (instead of segment 0x7c00) if EBDA
value is out of range
- also add upper limit check on EBDA value
- fix and simplify inline assembly operands in reloc_mbi_struct()
- use lret instead of retf
- renamed early_stack to wakeup_stack, defined and used now only
in wakeup.S
- aligned reloc.bin's end of .text to 16 bytes, so that checking
__bss_start == end works reliably
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To make future changes less error prone, and to slightly simplify a
possible future conversion to a relocatable trampoline even for the
multiboot path (pretty desirable given that we had to change the
trampoline base a number of times to escape collisions with firmware
placed data),
- remove final uses of bootsym_phys() from trampoline.S, allowing the
symbol to be undefined before including this file (to make sure no
new references get added)
- replace two easy to deal with uses of bootsym_phys() in head.S
- remove an easy to replace reference to BOOT_TRAMPOLINE
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to eliminate an initial hack in the EFI boot code (where
memory for the trampoline was just "claimed" instead of properly
allocated), the trampoline code must no longer make assumption on the
address at which it would be located. For the time being, the fixed
address is being retained for the traditional multiboot path.
As an additional benefit (at least from my pov) it allows confining
the visibility of the BOOT_TRAMPOLINE definition to just the boot
code.
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>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
| |
making Target Mode BIOS call. Fixes boot problems with some buggy
BIOSes.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
|
|
| |
* Generalise wakeup stack to general 'early stack' used everywhere.
* Ensure things that must be aligned are aligned.
* Remove some unused symbols.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
| |
BIOSes clobber GDTR. While we're here reset IDTR too, although it's
not really necessary.
Signed-off-by: John Byrne <john.l.byrne@hp.com>
Sigend-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
|
| |
* use memory 0x8c000-0x90000 to avoid trampling the area above
0x90000 -- some bootloaders may leave droppings in that region
* reserve 2kB for vga mode table -- limit of 128 VESA modes could
overflow the original 1kB allocation
* remove unnecessary alignment of trampoline GDT
|
| |
|
|
|
|
| |
modification of the trampoline GDT. Adjust trampoline base to
0x94000.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
| |
the wrong place.
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
| |
Still needs plumbing to dom0.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'vga=' boot option is extended as follows:
----------
'vga=<mode-specifier>[,keep]' where <mode-specifier> is one of:
'vga=ask':
display a vga menu of available modes
'vga=text-80x<rows>':
text mode, where <rows> is one of {25,28,30,34,43,50,60}
'vga=gfx-<width>x<height>x<depth>':
graphics mode, e.g., vga=gfx-1024x768x16
'vga=mode-<mode>:
specifies a mode as specified in 'vga=ask' menu
(NB. menu modes are displayed in hex, so mode numbers here must
be prefixed with '0x' (e.g., 'vga=mode-0x0318'))
The option 'keep' causes Xen to continue to print to the VGA console even
after domain 0 starts to boot. The default behaviour is to relinquish
control of the console to domain 0.
----------
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
| |
memory-map information (from int15{e820,e801,88} and int12 bios
calls).
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
| |
Bug tracked down by Stefan Berger.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
|
|
1. x86/64 Xen now relocates itself to physical high memory. This is
useful if we have devices that need very low memory, or if in
future we want to grant a 1:1 mapping of low physical memory to a
special 'native client domain'.
2. We now only map low 16MB RAM statically. All other RAM is mapped
dynamically within the constraints of the e820 map. It is
recommended never to map MMIO regions, and this change means that
Xen now obeys this constraint.
3. The CPU bootup trampoline is now permanently installed at
0x90000. This is necessary prereq for CPU hotplug.
4. Start-of-day asm is generally cleaned up and diff between x86/32
and x86/64 is reduced.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
