| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Augment watchdog_setup() to be able to possibly return an error, and introduce
watchdog_enabled() as a better alternative to knowing the architectures
internal details.
This patch does not change the x86 implementaion, beyond making it compile.
For header files, some includes of xen/nmi.h were only for the watchdog
functions, so are replaced rather than adding an extra include of
xen/watchdog.h
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... to match the actual functions.
Signed-off-by: Robbie VanVossen <robert.vanvossen@dornerworks.com>
Also make sure the source files defining these symbols include the
header declaring them (had we done so, the problem would have been
noticed long ago).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
They don't belong into the former.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Include the default XSM hook action as the first argument of the hook
to facilitate quick understanding of how the call site is expected to
be used (dom0-only, arbitrary guest, or device model). This argument
does not solely define how a given hook is interpreted, since any
changes to the hook's default action need to be made identically to
all callers of a hook (if there are multiple callers; most hooks only
have one), and may also require changing the arguments of the hook.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Xen hypervisor has two basic access control function calls:
IS_PRIV and the xsm_* functions. Most privileged operations currently
require that both checks succeed, and many times the checks are at
different locations in the code. This patch eliminates the explicit
and implicit IS_PRIV checks that are duplicated in XSM hooks.
When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations
of privilege checks have sometimes moved below argument validation,
error returns of some functions may change from EPERM to EINVAL or
ESRCH if called with invalid arguments and from a domain without
permission to perform the operation.
Some checks are removed due to non-obvious duplicates in their
callers:
* acpi_enter_sleep is checked in XENPF_enter_acpi_sleep
* map_domain_pirq has IS_PRIV_FOR checked in its callers:
* physdev_map_pirq checks when acquiring the RCU lock
* ioapic_guest_write is checked in PHYSDEVOP_apic_write
* PHYSDEVOP_{manage_pci_add,manage_pci_add_ext,pci_device_add} are
checked by xsm_resource_plug_pci in pci_add_device
* PHYSDEVOP_manage_pci_remove is checked by xsm_resource_unplug_pci
in pci_remove_device
* PHYSDEVOP_{restore_msi,restore_msi_ext} are checked by
xsm_resource_setup_pci in pci_restore_msi_state
* do_console_io has changed to IS_PRIV from an explicit domid==0
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: these changes don't make any difference on x86.
Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
an hypercall argument.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
|
|
|
|
|
|
|
|
|
| |
for common and x86 ones at least, to address the problem of storing
zero-extended values into the multicall result field otherwise.
Reported-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Explicity zero the memory backing the crash notes during setup.
This allows the crash environment to be rather more certain whether
the crash notes were actually written, rather than trusting that the
memory was clear beforehand.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-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>
|
|
|
|
|
| |
Signed-off-by: Andrew Cooper <andrew.cooper3@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question. This has certain problems including not being able to
allocate the crash buffers if the host is out of memory when crashing.
In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory. This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.
Therefore, allocate the crash note buffers at boot time.
Changes since v6:
* Tweak kexec_init() to use xzmalloc_array(), and to defer
registering the
crashdump keyhandler until the crash notes have been successfully
allocated.
Changes since v5:
* Introduce sizeof_cpu_notes to move calculation of note size into a
separate location.
* Tweak sizeof_note() to return size_t rather than int, as it is a
function based upon sizeof().
Changes since v4:
* Replace the current cpu crash note scheme of using void pointers
and hand calculating the size each time is needed, by a range
structure containing a pointer and a size. This removes duplicate
times where the size is calculated.
* Tweak kexec_get_cpu(). Don't fail if a cpu is offline because it
may already have crash notes, and may be up by the time a crash
happens. Split the error conditions up to return ERANGE for an
out-of-range cpu request rather than EINVAL. Finally, returning a
range of zeros is acceptable, so do this in preference to failing.
Changes since v3:
* Alter the spinlocks to avoid calling xmalloc/xfree while holding
the lock.
* Tidy up the coding style used.
Changes since v2:
* Allocate crash_notes dynamically using nr_cpu_ids at boot time,
rather than statically using NR_CPUS.
* Fix the incorrect use of signed integers for cpu id.
* Fix collateral damage to do_crashdump_trigger() and
crashdump_trigger_handler caused by reordering sizeof_note() and
setup_note()
* Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
No functional change.
* Change kexec_get_cpu() to attempt to allocate crash note buffers
in case we have more free memory now than when the pcpu came up.
* Now that there are two codepaths possibly allocating crash notes,
protect the allocation itself with a spinlock.
Changes since v1:
* Use cpu hotplug notifiers to handle allocating of the notes
buffers rather than assuming the boot state of cpus will be the
same as the crash state.
* Move crash_notes from being per_cpu. This is because the kdump
kernel elf binary put in the crash area is hard coded to physical
addresses which the dom0 kernel typically obtains at boot time.
If a cpu is offlined, its buffer should not be deallocated because
the kdump kernel would read junk when trying to get the crash
notes. Similarly, the same problem would occur if the cpu was
re-onlined later and its crash notes buffer was allocated
elsewhere.
* Only attempt to allocate buffers if a crash area has been
specified. Else, allocating crash note buffers is a waste of
space. Along with this, change the test in kexec_get_cpu to
return -EINVAL if no buffers have been allocated.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Fail with -ERANGE rather than silently truncating 64bit values (a
physical address and size) into 32bit integers for dom0 to consume.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Simplify the bitwise arithmetic a bit.
Signed-off-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
| |
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The former is the runtime equivalent of NR_CPUS (and users of NR_CPUS,
where necessary, get adjusted accordingly), while the latter is for the
sole use of determining the allocation size when dynamically allocating
CPU masks (done later in this series).
Adjust accessors to use either of the two to bound their bitmap
operations - which one gets used depends on whether accessing the bits
in the gap between nr_cpu_ids and nr_cpumask_bits is benign but more
efficient.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.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: Jan Beulich <jbeulich@novell.com>
|
|
|
|
|
|
|
|
|
|
| |
Add a new keyhandler that triggers all the side-effect-free
keyhandlers. This lets automated tests (and users) log the full set
of keyhandlers without having to be aware of which ones might reboot
the host.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since mixing data that only gets setup once and then (perhaps
frequently) gets read by remote CPUs with data that the local CPU may
modify (again, perhaps frequently) still causes undesirable cache
protocol related bus traffic, separate the former class of objects
from the latter.
These objects converted here are just picked based on their write-once
(or write-very-rarely) properties; perhaps some more adjustments may
be desirable subsequently. The primary users of the new sub-section
will result from the next patch.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
|
|
|
|
|
|
|
|
| |
- the machine address and the size of the vmcoreinfo area is returned
via the kexec_op(get_range) hypercall
- fill the vmcoreinfo data when the kexec_op(crash load) hypercall
is called
Signed-off-by: Itsuro Oda <oda@valinux.co.jp>
|
|
|
|
|
|
|
| |
xen/common/compat/kexec.c and and the resulting two-pass build
of xen/common/kexec.c is no longer needed.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
|
|
|
|
|
| |
Add an explicit kexec_load_unload_compat() using the same method
that was used to create kexec_range_compat()
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
|
|
|
|
|
|
| |
Add XLAT_kexec_range and use it to translate between xen_kexec_range_t
and compat_kexec_range_t. I missed this in my previous patche which
created the explicit definition of kexec_get_range_compat().
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Include compat/kexec.h at the top of xen/common/kexec.c to allow
kexec_get_range_compat() to be compiled outside of #ifndef COMPAT.
This will slightly simplify the explicit creation of other _compat()
functions and is needed for the eventual removal of
xen/common/compat/kexec.c
Note that the inclusion of compat/kexec.h needs to be protected
by #ifdef CONFIG_COMPAT, as the file doesn't exist otherwise.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unless I am mistaken, the compat functions are provided a stable ABI.
This includes providing a stable version of xen_kexec_range_t in the
form of compat_kexec_range_t. However, internally it doesn't really
matter how xen represents the data.
Currently the code provides for the creation of a compat version of
all kexec range functions, which use the compat_kexec_range_t
function. This is difficult to extend if range code exists outside of
xen/common/kexec.c.
The existence of "#ifdef CONFIG_X86_64" in the code suggests that some
of the range code might be better off in architecture specific code.
Furthermore, subsequent patches will introduce ia64-specific range
handling code, which really would be much better off somewhere in
arch/ia64/.
With this in mind, the handling of compat_kexec_range_t is changed
such that the code which reads and returns data from user-space
translates between compat_kexec_range_t and xen_kexec_range_t. As,
padding aside, the two structures are currently the same this is quite
easy. Things may get more tricky in the future, but I don't believe
this change is likely to make things significantly worse (or better)
in that regard. In any case, refactoring can occur again as required.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
|
|
| |
Signed-off-by: George Coker <gscoker@alpha.ncsc.mil>
|
|
|
|
|
|
|
| |
* switch to a suitable stack before jumping to compatibility mode.
* return the correct range for KEXEC_RANGE_MA_XEN.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir@xensource.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The alignment of info is 32bits in line with the elf specification.
This means that on 64 bit architectures accessing it directly may
result unaligned access and a panic. I have been experiencing
this on IA64.
It seems that a simple approach of having an crash_xen_info_t on
the stack and simply memcopying it into info at the end alleviates
the problem.
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>
|
|
|
|
|
|
|
|
|
|
| |
heap as well as code+data. This makes kdump work again after
13546:d86a96ca47a3
Also fix sizeof_note to correctly calculate the length of the name
field.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir@xensource.com>
|
|
|
|
|
| |
character-array type. Fix two bad callers.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
|
|
|
|
|
|
|
| |
Retain safe_strcpy(). It can hide the third argument to strlcpy() in
most cases.
Based on patches from Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
|
|
|
|
| |
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
|
|
|
|
|
| |
From: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some architectures, notably ia64, can automatically place
the crash kernel into an appropriate place if the start
address for crashkernel is specified as zero or omitted.
E.g. crashkernel=256M or crashkernel=256M@0
While xen does not actually have support for ia64 kexec,
I am working on it. And in any case this change should be harmless.
Just a small bit of infastructure that will make things easier in the
future.
This should also be possible on x86, now relocatable kernels
are reloacatble on x86. So once xen moves up to using linux ~2.6.19
it would make sense to look into implementing this.
The patch does 3 things.
* Firstly, parse_crashkernel() is modified to allows the size and start elements of kexec_crash_area
to be set to any value, including zero. Previously if either size or
start were specified as zero, they would both end up as zero.
* Secondly, when kexec_get() is called, if either the size or start
elements of kexec_crash_area are zero, then zero is passed
back to the hypercall caller for both values.
This gives the same behaviour as having parse_crashkernel() set
size and start to zero if either of them are zero, but it allows
architecture sepcific code called between the invocation of
parse_crashkernel() and kexec_get() to modify start (and size if
there was a reason). In particular, this allows the
architecture specific code to find a good start point if 0 is
specified.
* Lastly, it ads an additional check to the x86 setup code.
As this code currently does not know how to deal with a
0 start address, it doesn't reserve memory if start is 0.
This is neccessary as previously if start was specified as zero,
parse_crashkernel() would set size to zero, but that is
no longer the case, so a stronger check is needed.
I would really appreciate it if this patch was merged,
as I don't believe it harms anything, and it does allow
a nice path for moving forwards.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
|
|
| |
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
|
|
|
|
|
|
| |
struct/unions and the packed keyword.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
|
|
|
|
| |
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
|
|
|
|
|
| |
Also sync the tools/symbol.c symbol table generator with Linux.
Make section names generic (e.e.g, .init.text, .init.data, ...).
Signed-off-by: Keir Fraser <keir@xensource.com>
|