x86/vpmu: small fix for console logging beauty

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
KEXEC: Allocate crash notes on boot

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>
KEXEC: Allocate crash structures in low memory

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>
list maintainers of unmodified_drivers/linux-2.6/

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
unmodified drivers: hide xen_cpuid_base() in version 2.6.38+

Allow compilation of PVonHVM drivers with forward-ported xenlinux
sources in openSuSE 12.1.  xen_cpuid_base() is now in mainline, the copy
in the xen tree leads to a compilation error.  The current state leads
to a compile error:

/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/platform-pci.c:121: error: redefinition of 'xen_cpuid_base'
/usr/src/linux-3.0.13-0.11/arch/x86/include/asm/xen/hypervisor.h:43: error: previous definition of 'xen_cpuid_base' was here

The reason is that the kernel sources are searched before the xen
sources for asm/hypervisor.h:

/usr/src/linux-3.0.13-0.11/arch/x86/include/asm/hypervisor.h
/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include/asm/hypervisor.h

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
unmodified drivers: add pfn_is_ram helper for kdump

Register pfn_is_ram helper speed up reading /proc/vmcore in the kdump
kernel. It is compiled only if the kernel source is recent enough to
have the pfn_is_ram helper (v3.0-rc1, commit
997c136f518c5debd63847e78e2a8694f56dcf90).

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Jan Beulich <jbeulich@suse.com>
unmodified drivers: use upstream sync_bitops if available

The forward ported xenlinux sources in openSuSE 12.2 were switched from
the old synch_bitops to the sync_bitops since kernel version 3.3. Add
compat macros to use either old or new helpers depending on used kernel
source version.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Olaf Hering <olaf@aepfle.de>
kexec: Fix printing of paddr_t in 32bit mode.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>