From: Hari Bathini <hbathini@linux.ibm.com>
To: linuxppc-dev <linuxppc-dev@ozlabs.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Vasant Hegde <hegdevasant@linux.ibm.com>,
Nicholas Piggin <npiggin@gmail.com>,
Stewart Smith <stewart@linux.ibm.com>,
Daniel Axtens <dja@axtens.net>
Subject: [PATCH v2 06/16] powerpc/fadump: Update documentation about OPAL platform support
Date: Tue, 16 Apr 2019 16:04:27 +0530 [thread overview]
Message-ID: <155541086407.812.16892616275938068505.stgit@hbathini.in.ibm.com> (raw)
In-Reply-To: <155541065470.812.7120798773144842076.stgit@hbathini.in.ibm.com>
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>
---
Documentation/powerpc/firmware-assisted-dump.txt | 90 ++++++++++++----------
1 file changed, 51 insertions(+), 39 deletions(-)
diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.txt
index 62e75ef..844a229 100644
--- a/Documentation/powerpc/firmware-assisted-dump.txt
+++ b/Documentation/powerpc/firmware-assisted-dump.txt
@@ -70,7 +70,8 @@ as follows:
normal.
-- The freshly booted kernel will notice that there is a new
- node (ibm,dump-kernel) in the device tree, indicating that
+ node (ibm,dump-kernel on PSeries or ibm,opal/dump/result-table
+ 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
@@ -93,7 +94,9 @@ as follows:
Please note that the firmware-assisted dump feature
is only available on Power6 and above systems with recent
-firmware versions.
+firmware versions on PSeries (PowerVM) platform and Power9
+and above systems with recent firmware versions on PowerNV
+(OPAL) platform.
Implementation details:
----------------------
@@ -108,57 +111,66 @@ 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 | (Preserve area) | 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 Reservatio | |
+ V V | (Preserve area) | 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)
Fig. 1
o Memory Reservation during second kernel after crash
- Low memory Top of memory
- 0 boot memory size |
- | |<------------- Reserved dump area --------------->|
- V V |<---- Preserve area ----->| V
- +-----------+----------/ /---+---+----+--------+---+----+------+
- | | |CPU|HPTE| DUMP |HDR|ELF | |
- +-----------+----------/ /---+---+----+--------+---+----+------+
+ Low memory Top of memory
+ 0 boot memory size |
+ | |<--------------- Reserved dump area -------------->|
+ V V |<---- Preserve area ------->| |
+ +-----------+--------/ /---+---+----+-------+-----+-----+-------+
+ | | |///|////| DUMP | HDR | ELF | |
+ +-----------+--------/ /---+---+----+-------+-----+-----+-------+
| |
V V
Used by second /proc/vmcore
kernel to boot
Fig. 2
+ +---+
+ |///| -> Regions (CPU & HPTE) marked like this in the above figures
+ +---+ are not always present. For example, OPAL platform does not
+ have CPU & HPTE regions.
+
+
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)
next prev parent reply other threads:[~2019-04-16 10:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 10:32 [PATCH v2 00/16] Add FADump support on PowerNV platform Hari Bathini
2019-04-16 10:33 ` [PATCH v2 01/16] powerpc/fadump: move internal fadump code to a new file Hari Bathini
2019-04-16 10:33 ` [PATCH v2 02/16] powerpc/fadump: Improve fadump documentation Hari Bathini
2019-04-16 10:33 ` [PATCH v2 03/16] pseries/fadump: move out platform specific support from generic code Hari Bathini
2019-04-16 10:33 ` [PATCH v2 04/16] powerpc/fadump: use FADump instead of fadump for how it is pronounced Hari Bathini
2019-04-16 10:34 ` [PATCH v2 05/16] powerpc/fadump: enable fadump support on OPAL based POWER platform Hari Bathini
2019-04-16 10:34 ` Hari Bathini [this message]
2019-04-16 10:34 ` [PATCH v2 07/16] powerpc/fadump: consider reserved ranges while reserving memory Hari Bathini
2019-04-16 10:34 ` [PATCH v2 08/16] powerpc/fadump: consider reserved ranges while releasing memory Hari Bathini
2019-04-16 10:35 ` [PATCH v2 09/16] powernv/fadump: process architected register state data provided by firmware Hari Bathini
2019-05-07 14:13 ` Mahesh J Salgaonkar
2019-05-07 16:00 ` Segher Boessenkool
2019-05-09 4:42 ` Hari Bathini
2019-04-16 10:35 ` [PATCH v2 10/16] powernv/fadump: add support to preserve crash data on FADUMP disabled kernel Hari Bathini
2019-04-16 10:35 ` [PATCH v2 11/16] powerpc/fadump: update documentation about CONFIG_PRESERVE_FA_DUMP Hari Bathini
2019-04-16 10:35 ` [PATCH v2 12/16] powerpc/powernv: export /proc/opalcore for analysing opal crashes Hari Bathini
2019-05-08 0:25 ` Nicholas Piggin
2019-05-09 4:46 ` Hari Bathini
2019-04-16 10:35 ` [PATCH v2 13/16] powernv/fadump: Skip processing /proc/vmcore when only OPAL core exists Hari Bathini
2019-04-16 10:36 ` [PATCH v2 14/16] powernv/opalcore: provide an option to invalidate /proc/opalcore file Hari Bathini
2019-04-16 10:36 ` [PATCH v2 15/16] powernv/fadump: consider f/w load area Hari Bathini
2019-05-07 17:13 ` Mahesh J Salgaonkar
2019-05-09 4:50 ` Hari Bathini
2019-04-16 10:36 ` [PATCH v2 16/16] powernv/fadump: update documentation about option to release opalcore Hari Bathini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=155541086407.812.16892616275938068505.stgit@hbathini.in.ibm.com \
--to=hbathini@linux.ibm.com \
--cc=ananth@linux.ibm.com \
--cc=dja@axtens.net \
--cc=hegdevasant@linux.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mahesh@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=stewart@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).