From: Hari Bathini <hbathini@linux.ibm.com>
To: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Vasant Hegde <hegdevasant@linux.ibm.com>,
linuxppc-dev <linuxppc-dev@ozlabs.org>,
Stewart Smith <stewart@linux.ibm.com>
Subject: [PATCH 18/18] powerpc/fadump: Update documentation about backup area support
Date: Thu, 21 Feb 2019 23:07:31 +0530 [thread overview]
Message-ID: <155077065158.21014.4619439728235653815.stgit@hbathini.in.ibm.com> (raw)
In-Reply-To: <155077048463.21014.13936958730316555495.stgit@hbathini.in.ibm.com>
With backup area support available for FADump on PowerNV platform,
update FADump documentation with these details.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
Documentation/powerpc/firmware-assisted-dump.txt | 71 +++++++++++++---------
1 file changed, 43 insertions(+), 28 deletions(-)
diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.txt
index 6411449..42a0065 100644
--- a/Documentation/powerpc/firmware-assisted-dump.txt
+++ b/Documentation/powerpc/firmware-assisted-dump.txt
@@ -117,6 +117,17 @@ to ensure that crash data is preserved to process later.
e.g.
# echo 1 > /sys/kernel/fadump_release_opalcore
+To process dump on OPAL platform, additional meta data (PIR to
+Logical CPU map) from the crashing kernel is required. This info
+has to be backed up by the crashing kernel for capture kernel to
+use it in making sense of the register state data provided by the
+F/W. The start address of the area where this info is backed up
+is stored at the tail end of FADump crash info header. To indicate
+the presence of this additional meta data (backup info), the magic
+number field in FADump crash info header is overloaded as version
+identifier.
+
+
Implementation details:
----------------------
@@ -131,12 +142,12 @@ that are run. If there is dump data, then the
memory is held.
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
+hold CPU state, HPTE region, boot memory dump, FADump header, elfcore
+header and backup area, 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.
+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
@@ -150,19 +161,19 @@ 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 Reservatio | |
- V V | (Preserve area) | V
- +-----------+--------/ /---+---+----+-------+-----+-----+-------+
- | | |///|////| DUMP | HDR | ELF | |
- +-----------+--------/ /---+---+----+-------+-----+-----+-------+
- | ^ ^ ^ ^
- | | | | |
- \ CPU HPTE / |
- --------------------------------- |
- Boot memory content gets transferred |
- to reserved area by firmware at the |
+ Low memory Top of memory
+ 0 boot memory size |<---- Reserved dump area ---->| |
+ | | | Permanent Reservation | |
+ V V | (Preserve area) | V
+ +-----------+--------/ /---+---+----+-------+-----+----+--+-------+
+ | | |///|////| DUMP |HDR|/|ELF |//| |
+ +-----------+--------/ /---+---+----+-------+-----+----+--+-------+
+ | ^ ^ ^ ^ | ^^
+ | | | | | | ||
+ \ CPU HPTE / | \ / Backup Info
+ --------------------------------- | ----
+ Boot memory content gets transferred | Start address of
+ to reserved area by firmware at the | Backup Info.
time of crash. |
FADump Header
(meta area)
@@ -171,13 +182,13 @@ that were present in CMA region.
o Memory Reservation during second kernel after crash
- Low memory Top of memory
- 0 boot memory size |
- | |<--------------- Reserved dump area -------------->|
- V V |<---- Preserve area ------->| |
- +-----------+--------/ /---+---+----+-------+-----+-----+-------+
- | | |///|////| 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
@@ -185,9 +196,10 @@ that were present in CMA region.
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.
+ |///| -> Regions (CPU, HPTE, HDR extension & Backup area) marked
+ +---+ like this in the above figures are not always present.
+ For example, OPAL platform does not have CPU & HPTE regions
+ while PSeries platform doesn't use Backup area currently.
Currently the dump will be copied from /proc/vmcore to a new file upon
@@ -330,7 +342,10 @@ TODO:
2. Reserve the area of predefined size (say PAGE_SIZE) for this
structure and have unused area as reserved (initialized to zero)
for future field additions.
+
The advantage of approach 1 over 2 is we don't need to reserve extra space.
+ Using approach 1 to provide additional meta data on OPAL platform while
+ overloading magic number field as version identifier for version tracking.
---
Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
This document is based on the original documentation written for phyp
next prev parent reply other threads:[~2019-02-21 18:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-21 17:35 [PATCH 00/18] Add FADump support on PowerNV platform Hari Bathini
2019-02-21 17:35 ` [PATCH 01/18] powerpc/fadump: move internal fadump code to a new file Hari Bathini
2019-02-21 17:35 ` [PATCH 02/18] powerpc/fadump: Improve fadump documentation Hari Bathini
2019-02-21 17:35 ` [PATCH 03/18] pseries/fadump: move out platform specific support from generic code Hari Bathini
2019-02-21 17:35 ` [PATCH 04/18] powerpc/fadump: use FADump instead of fadump for how it is pronounced Hari Bathini
2019-02-21 17:35 ` [PATCH 05/18] powerpc/fadump: enable fadump support on OPAL based POWER platform Hari Bathini
2019-02-21 17:35 ` [PATCH 06/18] powerpc/fadump: Update documentation about OPAL platform support Hari Bathini
2019-02-21 17:36 ` [PATCH 07/18] powerpc/fadump: consider reserved ranges while reserving memory Hari Bathini
2019-02-21 17:36 ` [PATCH 08/18] powerpc/fadump: consider reserved ranges while releasing memory Hari Bathini
2019-02-21 17:36 ` [PATCH 09/18] powernv/fadump: process architected register state data provided by firmware Hari Bathini
2019-02-21 17:36 ` [PATCH 10/18] powernv/fadump: add support to preserve crash data on FADUMP disabled kernel Hari Bathini
2019-02-21 17:36 ` [PATCH 11/18] powerpc/fadump: update documentation about CONFIG_PRESERVE_FA_DUMP Hari Bathini
2019-02-21 17:36 ` [PATCH 12/18] powerpc/powernv: export /proc/opalcore for analysing opal crashes Hari Bathini
2019-02-21 17:36 ` [PATCH 13/18] powernv/fadump: Skip processing /proc/vmcore when only OPAL core exists Hari Bathini
2019-02-21 17:37 ` [PATCH 14/18] powernv/opalcore: provide an option to invalidate /proc/opalcore file Hari Bathini
2019-02-21 17:37 ` [PATCH 15/18] powernv/fadump: consider f/w load area Hari Bathini
2019-02-21 17:37 ` [PATCH 16/18] powernv/fadump: update documentation about option to release opalcore Hari Bathini
2019-02-21 17:37 ` [PATCH 17/18] powernv/fadump: use backup area to map PIR to logical CPUs Hari Bathini
2019-02-21 17:37 ` Hari Bathini [this message]
2019-02-27 3:37 ` [PATCH 00/18] Add FADump support on PowerNV platform Daniel Axtens
2019-02-28 5:02 ` Hari Bathini
2019-02-27 4:18 ` Nicholas Piggin
2019-02-28 5:24 ` 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=155077065158.21014.4619439728235653815.stgit@hbathini.in.ibm.com \
--to=hbathini@linux.ibm.com \
--cc=ananth@linux.ibm.com \
--cc=hegdevasant@linux.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mahesh@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--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).