linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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


  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).