mirror of
https://github.com/torvalds/linux.git
synced 2024-11-27 14:41:39 +00:00
powerpc/fadump: Update documentation about OPAL platform support
With FADump support now available on both pseries and OPAL platforms, update FADump documentation with these details. Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/156821361692.5656.11377757995827253404.stgit@hbathini.in.ibm.com
This commit is contained in:
Hari Bathini
Michael Ellerman
parent
a4e2e2ca2f
commit
fbcafdaea2
@ -46,10 +46,9 @@ as follows:
|
||||
These registered sections of memory are reserved by the first
|
||||
kernel during early boot.
|
||||
|
||||
- When a system crashes, the Power firmware will save
|
||||
the low memory (boot memory of size larger of 5% of system RAM
|
||||
or 256MB) of RAM to the previous registered region. It will
|
||||
also save system registers, and hardware PTE's.
|
||||
- When system crashes, the Power firmware will copy the registered
|
||||
low memory regions (boot memory) from source to destination area.
|
||||
It will also save hardware PTE's.
|
||||
|
||||
NOTE:
|
||||
The term 'boot memory' means size of the low memory chunk
|
||||
@ -61,9 +60,9 @@ as follows:
|
||||
the default calculated size. Use this option if default
|
||||
boot memory size is not sufficient for second kernel to
|
||||
boot successfully. For syntax of crashkernel= parameter,
|
||||
refer to Documentation/admin-guide/kdump/kdump.rst. If any offset is
|
||||
provided in crashkernel= parameter, it will be ignored
|
||||
as FADump uses a predefined offset to reserve memory
|
||||
refer to Documentation/admin-guide/kdump/kdump.rst. If any
|
||||
offset is provided in crashkernel= parameter, it will be
|
||||
ignored as FADump uses a predefined offset to reserve memory
|
||||
for boot memory dump preservation in case of a crash.
|
||||
|
||||
- After the low memory (boot memory) area has been saved, the
|
||||
@ -71,8 +70,9 @@ as follows:
|
||||
*not* clear the RAM. It will then launch the bootloader, as
|
||||
normal.
|
||||
|
||||
- The freshly booted kernel will notice that there is a new
|
||||
node (ibm,dump-kernel) in the device tree, indicating that
|
||||
- The freshly booted kernel will notice that there is a new node
|
||||
(rtas/ibm,kernel-dump on pSeries or ibm,opal/dump/mpipl-boot
|
||||
on OPAL platform) in the device tree, indicating that
|
||||
there is crash data available from a previous boot. During
|
||||
the early boot OS will reserve rest of the memory above
|
||||
boot memory size effectively booting with restricted memory
|
||||
@ -95,8 +95,11 @@ as follows:
|
||||
# echo 1 > /sys/kernel/fadump_release_mem
|
||||
|
||||
Please note that the firmware-assisted dump feature
|
||||
is only available on Power6 and above systems with recent
|
||||
firmware versions.
|
||||
is only available on POWER6 and above systems on pSeries
|
||||
(PowerVM) platform and POWER9 and above systems with OP940
|
||||
or later firmware versions on PowerNV (OPAL) platform.
|
||||
Note that, OPAL firmware exports ibm,opal/dump node when
|
||||
FADump is supported on PowerNV platform.
|
||||
|
||||
Implementation details:
|
||||
-----------------------
|
||||
@ -111,57 +114,76 @@ that are run. If there is dump data, then the
|
||||
/sys/kernel/fadump_release_mem file is created, and the reserved
|
||||
memory is held.
|
||||
|
||||
If there is no waiting dump data, then only the memory required
|
||||
to hold CPU state, HPTE region, boot memory dump and elfcore
|
||||
header, is usually reserved at an offset greater than boot memory
|
||||
size (see Fig. 1). This area is *not* released: this region will
|
||||
be kept permanently reserved, so that it can act as a receptacle
|
||||
for a copy of the boot memory content in addition to CPU state
|
||||
and HPTE region, in the case a crash does occur. Since this reserved
|
||||
memory area is used only after the system crash, there is no point in
|
||||
blocking this significant chunk of memory from production kernel.
|
||||
Hence, the implementation uses the Linux kernel's Contiguous Memory
|
||||
Allocator (CMA) for memory reservation if CMA is configured for kernel.
|
||||
With CMA reservation this memory will be available for applications to
|
||||
use it, while kernel is prevented from using it. With this FADump will
|
||||
still be able to capture all of the kernel memory and most of the user
|
||||
space memory except the user pages that were present in CMA region::
|
||||
If there is no waiting dump data, then only the memory required to
|
||||
hold CPU state, HPTE region, boot memory dump, FADump header and
|
||||
elfcore header, is usually reserved at an offset greater than boot
|
||||
memory size (see Fig. 1). This area is *not* released: this region
|
||||
will be kept permanently reserved, so that it can act as a receptacle
|
||||
for a copy of the boot memory content in addition to CPU state and
|
||||
HPTE region, in the case a crash does occur.
|
||||
|
||||
Since this reserved memory area is used only after the system crash,
|
||||
there is no point in blocking this significant chunk of memory from
|
||||
production kernel. Hence, the implementation uses the Linux kernel's
|
||||
Contiguous Memory Allocator (CMA) for memory reservation if CMA is
|
||||
configured for kernel. With CMA reservation this memory will be
|
||||
available for applications to use it, while kernel is prevented from
|
||||
using it. With this FADump will still be able to capture all of the
|
||||
kernel memory and most of the user space memory except the user pages
|
||||
that were present in CMA region::
|
||||
|
||||
o Memory Reservation during first kernel
|
||||
|
||||
Low memory Top of memory
|
||||
0 boot memory size |<--Reserved dump area --->| |
|
||||
| | | (Permanent Reservation) | |
|
||||
V V | | V
|
||||
+-----------+----------/ /---+---+----+--------+---+----+------+
|
||||
| | |CPU|HPTE| DUMP |HDR|ELF | |
|
||||
+-----------+----------/ /---+---+----+--------+---+----+------+
|
||||
| ^ ^
|
||||
| | |
|
||||
\ / |
|
||||
----------------------------------- FADump Header
|
||||
Boot memory content gets transferred (meta area)
|
||||
to reserved area by firmware at the
|
||||
time of crash
|
||||
Low memory Top of memory
|
||||
0 boot memory size |<--- Reserved dump area --->| |
|
||||
| | | Permanent Reservation | |
|
||||
V V | | V
|
||||
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
|
||||
| | |///|////| DUMP | HDR | ELF |////| |
|
||||
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
|
||||
| ^ ^ ^ ^ ^
|
||||
| | | | | |
|
||||
\ CPU HPTE / | |
|
||||
------------------------------ | |
|
||||
Boot memory content gets transferred | |
|
||||
to reserved area by firmware at the | |
|
||||
time of crash. | |
|
||||
FADump Header |
|
||||
(meta area) |
|
||||
|
|
||||
|
|
||||
Metadata: This area holds a metadata struture whose
|
||||
address is registered with f/w and retrieved in the
|
||||
second kernel after crash, on platforms that support
|
||||
tags (OPAL). Having such structure with info needed
|
||||
to process the crashdump eases dump capture process.
|
||||
|
||||
Fig. 1
|
||||
|
||||
|
||||
o Memory Reservation during second kernel after crash
|
||||
|
||||
Low memory Top of memory
|
||||
0 boot memory size |
|
||||
| |<----------- Crash preserved area --------------->|
|
||||
V V |<-- Reserved dump area -->| V
|
||||
+-----------+----------/ /---+---+----+--------+---+----+------+
|
||||
| | |CPU|HPTE| DUMP |HDR|ELF | |
|
||||
+-----------+----------/ /---+---+----+--------+---+----+------+
|
||||
| |
|
||||
V V
|
||||
Used by second /proc/vmcore
|
||||
Low memory Top of memory
|
||||
0 boot memory size |
|
||||
| |<------------ Crash preserved area ------------>|
|
||||
V V |<--- Reserved dump area --->| |
|
||||
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
|
||||
| | |///|////| DUMP | HDR | ELF |////| |
|
||||
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
|
||||
| |
|
||||
V V
|
||||
Used by second /proc/vmcore
|
||||
kernel to boot
|
||||
|
||||
+---+
|
||||
|///| -> Regions (CPU, HPTE & Metadata) marked like this in the above
|
||||
+---+ figures are not always present. For example, OPAL platform
|
||||
does not have CPU & HPTE regions while Metadata region is
|
||||
not supported on pSeries currently.
|
||||
|
||||
Fig. 2
|
||||
|
||||
|
||||
Currently the dump will be copied from /proc/vmcore to a new file upon
|
||||
user intervention. The dump data available through /proc/vmcore will be
|
||||
in ELF format. Hence the existing kdump infrastructure (kdump scripts)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user