tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

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 <sourabhjain@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240422195932.1583833-4-sourabhjain@linux.ibm.com

authored by

Sourabh Jain and committed by
Michael Ellerman 57e67001 bc446c5a

+42 -49
+42 -49
Documentation/arch/powerpc/firmware-assisted-dump.rst
··· 134 134 memory is held. 135 135 136 136 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. 143 143 144 144 Since this reserved memory area is used only after the system crash, 145 145 there is no point in blocking this significant chunk of memory from ··· 153 153 154 154 o Memory Reservation during first kernel 155 155 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) | 172 172 | 173 173 | 174 174 Metadata: This area holds a metadata structure whose ··· 186 186 0 boot memory size | 187 187 | |<------------ Crash preserved area ------------>| 188 188 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 + 196 203 197 204 +---+ 198 205 |///| -> Regions (CPU, HPTE & Metadata) marked like this in the above 199 206 +---+ figures are not always present. For example, OPAL platform 200 207 does not have CPU & HPTE regions while Metadata region is 201 208 not supported on pSeries currently. 209 + 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 202 215 203 216 Fig. 2 204 217 ··· 366 353 - Need to come up with the better approach to find out more 367 354 accurate boot memory size that is required for a kernel to 368 355 boot successfully when booted with restricted memory. 369 - - The FADump implementation introduces a FADump crash info structure 370 - in the scratch area before the ELF core header. The idea of introducing 371 - this structure is to pass some important crash info data to the second 372 - kernel which will help second kernel to populate ELF core header with 373 - correct data before it gets exported through /proc/vmcore. The current 374 - design implementation does not address a possibility of introducing 375 - additional fields (in future) to this structure without affecting 376 - compatibility. Need to come up with the better approach to address this. 377 - 378 - The possible approaches are: 379 - 380 - 1. Introduce version field for version tracking, bump up the version 381 - whenever a new field is added to the structure in future. The version 382 - field can be used to find out what fields are valid for the current 383 - version of the structure. 384 - 2. Reserve the area of predefined size (say PAGE_SIZE) for this 385 - structure and have unused area as reserved (initialized to zero) 386 - for future field additions. 387 - 388 - The advantage of approach 1 over 2 is we don't need to reserve extra space. 389 356 390 357 Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> 391 358