-
Notifications
You must be signed in to change notification settings - Fork 48
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Automatic merge of 'next-test' into merge-test (2024-04-22 23:54)
- Loading branch information
Showing
54 changed files
with
537 additions
and
404 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -38,3 +38,14 @@ Contact: [email protected] | |
Description: read only | ||
Provide information about the amount of memory reserved by | ||
FADump to save the crash dump in bytes. | ||
|
||
What: /sys/kernel/fadump/hotplug_ready | ||
Date: Apr 2024 | ||
Contact: [email protected] | ||
Description: read only | ||
Kdump udev rule re-registers fadump on memory add/remove events, | ||
primarily to update the elfcorehdr. This sysfs indicates the | ||
kdump udev rule that fadump re-registration is not required on | ||
memory add/remove events because elfcorehdr is now prepared in | ||
the second/fadump kernel. | ||
User: kexec-tools |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -134,12 +134,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 | ||
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. | ||
hold CPU state, HPTE region, boot memory dump, and FADump 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 | ||
|
@@ -153,22 +153,22 @@ 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 | | 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) | | ||
Low memory Top of memory | ||
0 boot memory size |<------ Reserved dump area ----->| | | ||
| | | Permanent Reservation | | | ||
V V | | V | ||
+-----------+-----/ /---+---+----+-----------+-------+----+-----+ | ||
| | |///|////| DUMP | HDR |////| | | ||
+-----------+-----/ /---+---+----+-----------+-------+----+-----+ | ||
| ^ ^ ^ ^ ^ | ||
| | | | | | | ||
\ CPU HPTE / | | | ||
-------------------------------- | | | ||
Boot memory content gets transferred | | | ||
to reserved area by firmware at the | | | ||
time of crash. | | | ||
FADump Header | | ||
(meta area) | | ||
| | ||
| | ||
Metadata: This area holds a metadata structure whose | ||
|
@@ -186,20 +186,33 @@ that were present in CMA region:: | |
0 boot memory size | | ||
| |<------------ Crash preserved area ------------>| | ||
V V |<--- Reserved dump area --->| | | ||
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+ | ||
| | |///|////| DUMP | HDR | ELF |////| | | ||
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+ | ||
| | | ||
V V | ||
Used by second /proc/vmcore | ||
kernel to boot | ||
+----+---+--+-----/ /---+---+----+-------+-----+-----+-------+ | ||
| |ELF| | |///|////| DUMP | HDR |/////| | | ||
+----+---+--+-----/ /---+---+----+-------+-----+-----+-------+ | ||
| | | | | | | ||
----- ------------------------------ --------------- | ||
\ | | | ||
\ | | | ||
\ | | | ||
\ | ---------------------------- | ||
\ | / | ||
\ | / | ||
\ | / | ||
/proc/vmcore | ||
|
||
|
||
+---+ | ||
|///| -> Regions (CPU, HPTE & Metadata) marked like this in the above | ||
+---+ figures are not always present. For example, OPAL platform | ||
does not have CPU & HPTE regions while Metadata region is | ||
not supported on pSeries currently. | ||
|
||
+---+ | ||
|ELF| -> elfcorehdr, it is created in second kernel after crash. | ||
+---+ | ||
|
||
Note: Memory from 0 to the boot memory size is used by second kernel | ||
|
||
Fig. 2 | ||
|
||
|
||
|
@@ -353,26 +366,6 @@ TODO: | |
- Need to come up with the better approach to find out more | ||
accurate boot memory size that is required for a kernel to | ||
boot successfully when booted with restricted memory. | ||
- The FADump implementation introduces a FADump crash info structure | ||
in the scratch area before the ELF core header. The idea of introducing | ||
this structure is to pass some important crash info data to the second | ||
kernel which will help second kernel to populate ELF core header with | ||
correct data before it gets exported through /proc/vmcore. The current | ||
design implementation does not address a possibility of introducing | ||
additional fields (in future) to this structure without affecting | ||
compatibility. Need to come up with the better approach to address this. | ||
|
||
The possible approaches are: | ||
|
||
1. Introduce version field for version tracking, bump up the version | ||
whenever a new field is added to the structure in future. The version | ||
field can be used to find out what fields are valid for the current | ||
version of the structure. | ||
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. | ||
|
||
Author: Mahesh Salgaonkar <[email protected]> | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.