| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
The emacs variable to set the C style from a local variable block is
c-file-style, not c-set-style.
Signed-off-by: David Vrabel <david.vrabel@citrix.com
|
| |
|
|
|
|
|
|
| |
Fix the build where !CONFIG_KEXEC (e.g., arm) by providing a default
crashinfo_maxaddr_bits.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
as the CPU crash notes will go into the xenheap, which tends to be in
upper memory. This causes problems on machines with more than 64GB
(or 4GB if no PAE support) of ram as the crashkernel physically cant
access the crash notes.
The solution is to force Xen to allocate certain structures in lower
memory. This is achieved by introducing two new command line
parameters; low_crashinfo and crashinfo_maxaddr. Because of the
potential impact on 32bit PV guests, and that this problem does not
exist for 64bit dom0 on 64bit Xen, this new functionality defaults to
the codebase's previous behavior, requiring the user to explicitly
add extra command line parameters to change the behavior.
This patch consists of 3 logically distinct but closely related
changes.
1) Add the two new command line parameters.
2) Change crash note allocation to use lower memory when instructed.
3) Change the conring buffer to use lower memory when instructed.
There result is that the crash notes and console ring will be placed
in lower memory so useful information can be recovered in the case of
a crash.
Changes since v1:
- Patch xen-command-line.markdown to document new options
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
| |
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce the boolean variable 'kexecing' which indicates to functions
whether we are on the kexec path or not. This is used by
disable_local_APIC() to try and revert the APIC mode back to how it
was found on boot.
We also need some fudging of the x2apic_enabled variable. It is used
in multiple places over the codebase to mean multiple things,
including:
What did the user specifify on the command line?
Did the BIOS boot me in x2apic mode?
Is the BSP Local APIC in x2apic mode?
What mode is my Local APIC in?
Therefore, set it up to prevent a protection fault when disabling the
IOAPICs. (In this case, it is used in the "What mode is my Local APIC
in?" case, so the processor doesnt suffer a protection fault because
of trying to use x2apic MSRs when it should be using xapic MMIO)
Finally, make sure that interrupts are disabled when jumping into the
purgatory code. It would be bad to service interrupts in the Xen
context when the next kernel is booting.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
| |
|
|
|
|
|
|
| |
Move all extern declarations into appropriate header files.
This also fixes up a few places where the caller and the definition
had different signatures.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
The hypervisor writes some data structure infos into the elf note
section of the vmcore to enable interpretation of the xen structures
by kexec/kdump.
The info of the offset of _domain in page_info was just wrong on
non-ia64 systems.
Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quoting the original Linux patch's description:
"This patch adds a extended crashkernel syntax that makes the value of
reserved system RAM dependent on the system RAM itself:
crashkernel=3D<range1>:<size1>[,<range2>:<size2>,...][@offset]
range=3Dstart-[end]
For example:
crashkernel=3D512M-2G:64M,2G-:128M
The motivation comes from distributors that configure their
crashkernel command line automatically with some configuration tool
(YaST, you know ;)). Of course that tool knows the value of System
RAM, but if the user removes RAM, then the system becomes unbootable
or at least unusable and error handling is very difficult."
For x86, other than Linux we pass the actual amount of RAM rather than
the highest page's address (to cope with sparse physical address
maps).
This still needs to be hooked up for ia64.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
| |
Introduce machine_kexec_get to allow architecture-specific handling of
the xen region. x86_64 is currently different to x86_32 and ia64.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Ported from Linux, this shuts down iosapic before preforming kexec.
This resolves a problem whereby the serial port on an HP RX2620
(which uses IOSAPIC) was not able to accept input. It probably
resolves a bunch of other as yet unseen problems too.
Thanks to Takebe-san for working out the solution to this puzzle.
Cc: Akio Takebe <takebe_akio@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
| |
|
|
|
|
|
|
|
| |
arch specific machine_kexec.c with the other arch specific kexec
functions.
IA64 already had a stub in both kexec.h and machine_kexec.c.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
|
| |
|
|
|
| |
kdump is not in use.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
| |
reflect its purpose.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
|
|
|
This patch implements the generic portion of the Kexec / Kdump port to Xen.
Signed-Off-By: Magnus Damm <magnus@valinux.co.jp>
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
