Skip to content

Commit 3e53919

Browse files
sourabhjainsmpe
authored andcommitted
Documentation/powerpc: update fadump implementation details
The patch titled ("powerpc: make fadump resilient with memory add/remove events") has made significant changes to the implementation of fadump, particularly on elfcorehdr creation and fadump crash info header structure. Therefore, updating the fadump implementation documentation to reflect those changes. Following updates are done to firmware assisted dump documentation: 1. The elfcorehdr is no longer stored after fadump HDR in the reserved dump area. Instead, the second kernel dynamically allocates memory for the elfcorehdr within the address range from 0 to the boot memory size. Therefore, update figures 1 and 2 of Memory Reservation during the first and second kernels to reflect this change. 2. A version field has been added to the fadump header to manage the future changes to fadump crash info header structure without changing the fadump header magic number in the future. Therefore, remove the corresponding TODO from the document. Signed-off-by: Sourabh Jain <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
1 parent 7d27785 commit 3e53919

File tree

1 file changed

+42
-49
lines changed

1 file changed

+42
-49
lines changed

Documentation/arch/powerpc/firmware-assisted-dump.rst

Lines changed: 42 additions & 49 deletions
Original file line numberDiff line numberDiff line change
@@ -134,12 +134,12 @@ that are run. If there is dump data, then the
134134
memory is held.
135135

136136
If there is no waiting dump data, then only the memory required to
137-
hold CPU state, HPTE region, boot memory dump, FADump header and
138-
elfcore header, is usually reserved at an offset greater than boot
139-
memory size (see Fig. 1). This area is *not* released: this region
140-
will be kept permanently reserved, so that it can act as a receptacle
141-
for a copy of the boot memory content in addition to CPU state and
142-
HPTE region, in the case a crash does occur.
137+
hold CPU state, HPTE region, boot memory dump, and FADump header is
138+
usually reserved at an offset greater than boot memory size (see Fig. 1).
139+
This area is *not* released: this region will be kept permanently
140+
reserved, so that it can act as a receptacle for a copy of the boot
141+
memory content in addition to CPU state and HPTE region, in the case
142+
a crash does occur.
143143

144144
Since this reserved memory area is used only after the system crash,
145145
there is no point in blocking this significant chunk of memory from
@@ -153,22 +153,22 @@ that were present in CMA region::
153153

154154
o Memory Reservation during first kernel
155155

156-
Low memory Top of memory
157-
0 boot memory size |<--- Reserved dump area --->| |
158-
| | | Permanent Reservation | |
159-
V V | | V
160-
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
161-
| | |///|////| DUMP | HDR | ELF |////| |
162-
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
163-
| ^ ^ ^ ^ ^
164-
| | | | | |
165-
\ CPU HPTE / | |
166-
------------------------------ | |
167-
Boot memory content gets transferred | |
168-
to reserved area by firmware at the | |
169-
time of crash. | |
170-
FADump Header |
171-
(meta area) |
156+
Low memory Top of memory
157+
0 boot memory size |<------ Reserved dump area ----->| |
158+
| | | Permanent Reservation | |
159+
V V | | V
160+
+-----------+-----/ /---+---+----+-----------+-------+----+-----+
161+
| | |///|////| DUMP | HDR |////| |
162+
+-----------+-----/ /---+---+----+-----------+-------+----+-----+
163+
| ^ ^ ^ ^ ^
164+
| | | | | |
165+
\ CPU HPTE / | |
166+
-------------------------------- | |
167+
Boot memory content gets transferred | |
168+
to reserved area by firmware at the | |
169+
time of crash. | |
170+
FADump Header |
171+
(meta area) |
172172
|
173173
|
174174
Metadata: This area holds a metadata structure whose
@@ -186,20 +186,33 @@ that were present in CMA region::
186186
0 boot memory size |
187187
| |<------------ Crash preserved area ------------>|
188188
V V |<--- Reserved dump area --->| |
189-
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
190-
| | |///|////| DUMP | HDR | ELF |////| |
191-
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
192-
| |
193-
V V
194-
Used by second /proc/vmcore
195-
kernel to boot
189+
+----+---+--+-----/ /---+---+----+-------+-----+-----+-------+
190+
| |ELF| | |///|////| DUMP | HDR |/////| |
191+
+----+---+--+-----/ /---+---+----+-------+-----+-----+-------+
192+
| | | | | |
193+
----- ------------------------------ ---------------
194+
\ | |
195+
\ | |
196+
\ | |
197+
\ | ----------------------------
198+
\ | /
199+
\ | /
200+
\ | /
201+
/proc/vmcore
202+
196203

197204
+---+
198205
|///| -> Regions (CPU, HPTE & Metadata) marked like this in the above
199206
+---+ figures are not always present. For example, OPAL platform
200207
does not have CPU & HPTE regions while Metadata region is
201208
not supported on pSeries currently.
202209

210+
+---+
211+
|ELF| -> elfcorehdr, it is created in second kernel after crash.
212+
+---+
213+
214+
Note: Memory from 0 to the boot memory size is used by second kernel
215+
203216
Fig. 2
204217

205218

@@ -353,26 +366,6 @@ TODO:
353366
- Need to come up with the better approach to find out more
354367
accurate boot memory size that is required for a kernel to
355368
boot successfully when booted with restricted memory.
356-
- The FADump implementation introduces a FADump crash info structure
357-
in the scratch area before the ELF core header. The idea of introducing
358-
this structure is to pass some important crash info data to the second
359-
kernel which will help second kernel to populate ELF core header with
360-
correct data before it gets exported through /proc/vmcore. The current
361-
design implementation does not address a possibility of introducing
362-
additional fields (in future) to this structure without affecting
363-
compatibility. Need to come up with the better approach to address this.
364-
365-
The possible approaches are:
366-
367-
1. Introduce version field for version tracking, bump up the version
368-
whenever a new field is added to the structure in future. The version
369-
field can be used to find out what fields are valid for the current
370-
version of the structure.
371-
2. Reserve the area of predefined size (say PAGE_SIZE) for this
372-
structure and have unused area as reserved (initialized to zero)
373-
for future field additions.
374-
375-
The advantage of approach 1 over 2 is we don't need to reserve extra space.
376369

377370
Author: Mahesh Salgaonkar <[email protected]>
378371

0 commit comments

Comments
 (0)