powerpc/fadump: Improve fadump documentation

The figures depicting FADump's (Firmware-Assisted Dump) memory layout
are missing some finer details like different memory regions and what
they represent. Improve the documentation by updating those 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/156821322070.5656.8194734198500730487.stgit@hbathini.in.ibm.com
This commit is contained in:
Hari Bathini 2019-09-11 20:17:07 +05:30 коммит произвёл Michael Ellerman
Родитель 7f0ad11d3f
Коммит 8468d15545
1 изменённых файлов: 33 добавлений и 28 удалений

Просмотреть файл

@ -76,8 +76,9 @@ as follows:
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
size. This will make sure that the second kernel will not
touch any of the dump memory area.
size. This will make sure that this kernel (also, referred
to as second kernel or capture kernel) will not touch any
of the dump memory area.
- User-space tools will read /proc/vmcore to obtain the contents
of memory, which holds the previous crashed kernel dump in ELF
@ -128,42 +129,46 @@ 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 -->| |
V V | Permanent Reservation | V
+-----------+----------/ /---+---+----+-----------+----+------+
| | |CPU|HPTE| DUMP |ELF | |
+-----------+----------/ /---+---+----+-----------+----+------+
| ^
| |
\ /
-------------------------------------------
Boot memory content gets transferred 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
+-----------+----------/ /---+---+----+--------+---+----+------+
| | |CPU|HPTE| DUMP |HDR|ELF | |
+-----------+----------/ /---+---+----+--------+---+----+------+
| ^ ^
| | |
\ / |
----------------------------------- FADump Header
Boot memory content gets transferred (meta area)
to reserved area by firmware at the
time of crash
Fig. 1
o Memory Reservation during second kernel after crash
Low memory Top of memory
0 boot memory size |
| |<------------- Reserved dump area ----------- -->|
V V V
+-----------+----------/ /---+---+----+-----------+----+------+
| | |CPU|HPTE| DUMP |ELF | |
+-----------+----------/ /---+---+----+-----------+----+------+
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
kernel to boot
Fig. 2
Currently the dump will be copied from /proc/vmcore to a
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) to save the dump works fine with
minor modifications.
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)
to save the dump works fine with minor modifications. KDump scripts on
major Distro releases have already been modified to work seemlessly (no
user intervention in saving the dump) when FADump is used, instead of
KDump, as dump mechanism.
The tools to examine the dump will be same as the ones
used for kdump.