2019-09-11 20:16:21 +05:30
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
|
|
|
|
/*
|
|
|
|
|
* Firmware-Assisted Dump internal code.
|
|
|
|
|
*
|
|
|
|
|
* Copyright 2011, Mahesh Salgaonkar, IBM Corporation.
|
|
|
|
|
* Copyright 2019, Hari Bathini, IBM Corporation.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _ASM_POWERPC_FADUMP_INTERNAL_H
|
|
|
|
|
#define _ASM_POWERPC_FADUMP_INTERNAL_H
|
|
|
|
|
|
2019-09-11 20:27:39 +05:30
|
|
|
/* Maximum number of memory regions kernel supports */
|
|
|
|
|
#define FADUMP_MAX_MEM_REGS 128
|
|
|
|
|
|
2019-09-11 20:26:03 +05:30
|
|
|
#ifndef CONFIG_PRESERVE_FA_DUMP
|
2019-09-11 20:16:21 +05:30
|
|
|
|
|
|
|
|
/* The upper limit percentage for user specified boot memory size (25%) */
|
|
|
|
|
#define MAX_BOOT_MEM_RATIO 4
|
|
|
|
|
|
|
|
|
|
#define memblock_num_regions(memblock_type) (memblock.memblock_type.cnt)
|
|
|
|
|
|
|
|
|
|
/* FAD commands */
|
|
|
|
|
#define FADUMP_REGISTER 1
|
|
|
|
|
#define FADUMP_UNREGISTER 2
|
|
|
|
|
#define FADUMP_INVALIDATE 3
|
|
|
|
|
|
2019-09-11 20:18:14 +05:30
|
|
|
/*
|
|
|
|
|
* Copy the ascii values for first 8 characters from a string into u64
|
|
|
|
|
* variable at their respective indexes.
|
|
|
|
|
* e.g.
|
|
|
|
|
* The string "FADMPINF" will be converted into 0x4641444d50494e46
|
|
|
|
|
*/
|
|
|
|
|
static inline u64 fadump_str_to_u64(const char *str)
|
|
|
|
|
{
|
|
|
|
|
u64 val = 0;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < sizeof(val); i++)
|
|
|
|
|
val = (*str) ? (val << 8) | *str++ : val << 8;
|
|
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define FADUMP_CPU_UNKNOWN (~((u32)0))
|
|
|
|
|
|
powerpc: make fadump resilient with memory add/remove events
Due to changes in memory resources caused by either memory hotplug or
online/offline events, the elfcorehdr, which describes the CPUs and
memory of the crashed kernel to the kernel that collects the dump (known
as second/fadump kernel), becomes outdated. Consequently, attempting
dump collection with an outdated elfcorehdr can lead to failed or
inaccurate dump collection.
Memory hotplug or online/offline events is referred as memory add/remove
events in reset of the commit message.
The current solution to address the aforementioned issue is as follows:
Monitor memory add/remove events in userspace using udev rules, and
re-register fadump whenever there are changes in memory resources. This
leads to the creation of a new elfcorehdr with updated system memory
information.
There are several notable issues associated with re-registering fadump
for every memory add/remove events.
1. Bulk memory add/remove events with udev-based fadump re-registration
can lead to race conditions and, more importantly, it creates a wide
window during which fadump is inactive until all memory add/remove
events are settled.
2. Re-registering fadump for every memory add/remove event is
inefficient.
3. The memory for elfcorehdr is allocated based on the memblock regions
available during early boot and remains fixed thereafter. However, if
elfcorehdr is later recreated with additional memblock regions, its
size will increase, potentially leading to memory corruption.
Address the aforementioned challenges by shifting the creation of
elfcorehdr from the first kernel (also referred as the crashed kernel),
where it was created and frequently recreated for every memory
add/remove event, to the fadump kernel. As a result, the elfcorehdr only
needs to be created once, thus eliminating the necessity to re-register
fadump during memory add/remove events.
At present, the first kernel prepares fadump header and stores it in the
fadump reserved area. The fadump header includes the start address of
the elfcorehdr, crashing CPU details, and other relevant information. In
the event of a crash in the first kernel, the second/fadump boots and
accesses the fadump header prepared by the first kernel. It then
performs the following steps in a platform-specific function
[rtas|opal]_fadump_process:
1. Sanity check for fadump header
2. Update CPU notes in elfcorehdr
Along with the above, update the setup_fadump()/fadump.c to create
elfcorehdr and set its address to the global variable elfcorehdr_addr
for the vmcore module to process it in the second/fadump kernel.
Section below outlines the information required to create the elfcorehdr
and the changes made to make it available to the fadump kernel if it's
not already.
To create elfcorehdr, the following crashed kernel information is
required: CPU notes, vmcoreinfo, and memory ranges.
At present, the CPU notes are already prepared in the fadump kernel, so
no changes are needed in that regard. The fadump kernel has access to
all crashed kernel memory regions, including boot memory regions that
are relocated by firmware to fadump reserved areas, so no changes for
that either. However, it is necessary to add new members to the fadump
header, i.e., the 'fadump_crash_info_header' structure, in order to pass
the crashed kernel's vmcoreinfo address and its size to fadump kernel.
In addition to the vmcoreinfo address and size, there are a few other
attributes also added to the fadump_crash_info_header structure.
1. version:
It stores the fadump header version, which is currently set to 1.
This provides flexibility to update the fadump crash info header in
the future without changing the magic number. For each change in the
fadump header, the version will be increased. This will help the
updated kernel determine how to handle kernel dumps from older
kernels. The magic number remains relevant for checking fadump header
corruption.
2. pt_regs_sz/cpu_mask_sz:
Store size of pt_regs and cpu_mask structure of first kernel. These
attributes are used to prevent dump processing if the sizes of
pt_regs or cpu_mask structure differ between the first and fadump
kernels.
Note: if either first/crashed kernel or second/fadump kernel do not have
the changes introduced here then kernel fail to collect the dump and
prints relevant error message on the console.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240422195932.1583833-2-sourabhjain@linux.ibm.com
2024-04-23 01:29:30 +05:30
|
|
|
/*
|
|
|
|
|
* The introduction of new fields in the fadump crash info header has
|
|
|
|
|
* led to a change in the magic key from `FADMPINF` to `FADMPSIG` for
|
|
|
|
|
* identifying a kernel crash from an old kernel.
|
|
|
|
|
*
|
|
|
|
|
* To prevent the need for further changes to the magic number in the
|
|
|
|
|
* event of future modifications to the fadump crash info header, a
|
|
|
|
|
* version field has been introduced to track the fadump crash info
|
|
|
|
|
* header version.
|
|
|
|
|
*
|
|
|
|
|
* Consider a few points before adding new members to the fadump crash info
|
|
|
|
|
* header structure:
|
|
|
|
|
*
|
|
|
|
|
* - Append new members; avoid adding them in between.
|
|
|
|
|
* - Non-primitive members should have a size member as well.
|
|
|
|
|
* - For every change in the fadump header, increment the
|
|
|
|
|
* fadump header version. This helps the updated kernel decide how to
|
|
|
|
|
* handle kernel dumps from older kernels.
|
|
|
|
|
*/
|
|
|
|
|
#define FADUMP_CRASH_INFO_MAGIC_OLD fadump_str_to_u64("FADMPINF")
|
|
|
|
|
#define FADUMP_CRASH_INFO_MAGIC fadump_str_to_u64("FADMPSIG")
|
|
|
|
|
#define FADUMP_HEADER_VERSION 1
|
2019-09-11 20:16:21 +05:30
|
|
|
|
|
|
|
|
/* fadump crash info structure */
|
|
|
|
|
struct fadump_crash_info_header {
|
|
|
|
|
u64 magic_number;
|
powerpc: make fadump resilient with memory add/remove events
Due to changes in memory resources caused by either memory hotplug or
online/offline events, the elfcorehdr, which describes the CPUs and
memory of the crashed kernel to the kernel that collects the dump (known
as second/fadump kernel), becomes outdated. Consequently, attempting
dump collection with an outdated elfcorehdr can lead to failed or
inaccurate dump collection.
Memory hotplug or online/offline events is referred as memory add/remove
events in reset of the commit message.
The current solution to address the aforementioned issue is as follows:
Monitor memory add/remove events in userspace using udev rules, and
re-register fadump whenever there are changes in memory resources. This
leads to the creation of a new elfcorehdr with updated system memory
information.
There are several notable issues associated with re-registering fadump
for every memory add/remove events.
1. Bulk memory add/remove events with udev-based fadump re-registration
can lead to race conditions and, more importantly, it creates a wide
window during which fadump is inactive until all memory add/remove
events are settled.
2. Re-registering fadump for every memory add/remove event is
inefficient.
3. The memory for elfcorehdr is allocated based on the memblock regions
available during early boot and remains fixed thereafter. However, if
elfcorehdr is later recreated with additional memblock regions, its
size will increase, potentially leading to memory corruption.
Address the aforementioned challenges by shifting the creation of
elfcorehdr from the first kernel (also referred as the crashed kernel),
where it was created and frequently recreated for every memory
add/remove event, to the fadump kernel. As a result, the elfcorehdr only
needs to be created once, thus eliminating the necessity to re-register
fadump during memory add/remove events.
At present, the first kernel prepares fadump header and stores it in the
fadump reserved area. The fadump header includes the start address of
the elfcorehdr, crashing CPU details, and other relevant information. In
the event of a crash in the first kernel, the second/fadump boots and
accesses the fadump header prepared by the first kernel. It then
performs the following steps in a platform-specific function
[rtas|opal]_fadump_process:
1. Sanity check for fadump header
2. Update CPU notes in elfcorehdr
Along with the above, update the setup_fadump()/fadump.c to create
elfcorehdr and set its address to the global variable elfcorehdr_addr
for the vmcore module to process it in the second/fadump kernel.
Section below outlines the information required to create the elfcorehdr
and the changes made to make it available to the fadump kernel if it's
not already.
To create elfcorehdr, the following crashed kernel information is
required: CPU notes, vmcoreinfo, and memory ranges.
At present, the CPU notes are already prepared in the fadump kernel, so
no changes are needed in that regard. The fadump kernel has access to
all crashed kernel memory regions, including boot memory regions that
are relocated by firmware to fadump reserved areas, so no changes for
that either. However, it is necessary to add new members to the fadump
header, i.e., the 'fadump_crash_info_header' structure, in order to pass
the crashed kernel's vmcoreinfo address and its size to fadump kernel.
In addition to the vmcoreinfo address and size, there are a few other
attributes also added to the fadump_crash_info_header structure.
1. version:
It stores the fadump header version, which is currently set to 1.
This provides flexibility to update the fadump crash info header in
the future without changing the magic number. For each change in the
fadump header, the version will be increased. This will help the
updated kernel determine how to handle kernel dumps from older
kernels. The magic number remains relevant for checking fadump header
corruption.
2. pt_regs_sz/cpu_mask_sz:
Store size of pt_regs and cpu_mask structure of first kernel. These
attributes are used to prevent dump processing if the sizes of
pt_regs or cpu_mask structure differ between the first and fadump
kernels.
Note: if either first/crashed kernel or second/fadump kernel do not have
the changes introduced here then kernel fail to collect the dump and
prints relevant error message on the console.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240422195932.1583833-2-sourabhjain@linux.ibm.com
2024-04-23 01:29:30 +05:30
|
|
|
u32 version;
|
2019-09-11 20:16:21 +05:30
|
|
|
u32 crashing_cpu;
|
powerpc: make fadump resilient with memory add/remove events
Due to changes in memory resources caused by either memory hotplug or
online/offline events, the elfcorehdr, which describes the CPUs and
memory of the crashed kernel to the kernel that collects the dump (known
as second/fadump kernel), becomes outdated. Consequently, attempting
dump collection with an outdated elfcorehdr can lead to failed or
inaccurate dump collection.
Memory hotplug or online/offline events is referred as memory add/remove
events in reset of the commit message.
The current solution to address the aforementioned issue is as follows:
Monitor memory add/remove events in userspace using udev rules, and
re-register fadump whenever there are changes in memory resources. This
leads to the creation of a new elfcorehdr with updated system memory
information.
There are several notable issues associated with re-registering fadump
for every memory add/remove events.
1. Bulk memory add/remove events with udev-based fadump re-registration
can lead to race conditions and, more importantly, it creates a wide
window during which fadump is inactive until all memory add/remove
events are settled.
2. Re-registering fadump for every memory add/remove event is
inefficient.
3. The memory for elfcorehdr is allocated based on the memblock regions
available during early boot and remains fixed thereafter. However, if
elfcorehdr is later recreated with additional memblock regions, its
size will increase, potentially leading to memory corruption.
Address the aforementioned challenges by shifting the creation of
elfcorehdr from the first kernel (also referred as the crashed kernel),
where it was created and frequently recreated for every memory
add/remove event, to the fadump kernel. As a result, the elfcorehdr only
needs to be created once, thus eliminating the necessity to re-register
fadump during memory add/remove events.
At present, the first kernel prepares fadump header and stores it in the
fadump reserved area. The fadump header includes the start address of
the elfcorehdr, crashing CPU details, and other relevant information. In
the event of a crash in the first kernel, the second/fadump boots and
accesses the fadump header prepared by the first kernel. It then
performs the following steps in a platform-specific function
[rtas|opal]_fadump_process:
1. Sanity check for fadump header
2. Update CPU notes in elfcorehdr
Along with the above, update the setup_fadump()/fadump.c to create
elfcorehdr and set its address to the global variable elfcorehdr_addr
for the vmcore module to process it in the second/fadump kernel.
Section below outlines the information required to create the elfcorehdr
and the changes made to make it available to the fadump kernel if it's
not already.
To create elfcorehdr, the following crashed kernel information is
required: CPU notes, vmcoreinfo, and memory ranges.
At present, the CPU notes are already prepared in the fadump kernel, so
no changes are needed in that regard. The fadump kernel has access to
all crashed kernel memory regions, including boot memory regions that
are relocated by firmware to fadump reserved areas, so no changes for
that either. However, it is necessary to add new members to the fadump
header, i.e., the 'fadump_crash_info_header' structure, in order to pass
the crashed kernel's vmcoreinfo address and its size to fadump kernel.
In addition to the vmcoreinfo address and size, there are a few other
attributes also added to the fadump_crash_info_header structure.
1. version:
It stores the fadump header version, which is currently set to 1.
This provides flexibility to update the fadump crash info header in
the future without changing the magic number. For each change in the
fadump header, the version will be increased. This will help the
updated kernel determine how to handle kernel dumps from older
kernels. The magic number remains relevant for checking fadump header
corruption.
2. pt_regs_sz/cpu_mask_sz:
Store size of pt_regs and cpu_mask structure of first kernel. These
attributes are used to prevent dump processing if the sizes of
pt_regs or cpu_mask structure differ between the first and fadump
kernels.
Note: if either first/crashed kernel or second/fadump kernel do not have
the changes introduced here then kernel fail to collect the dump and
prints relevant error message on the console.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240422195932.1583833-2-sourabhjain@linux.ibm.com
2024-04-23 01:29:30 +05:30
|
|
|
u64 vmcoreinfo_raddr;
|
|
|
|
|
u64 vmcoreinfo_size;
|
|
|
|
|
u32 pt_regs_sz;
|
|
|
|
|
u32 cpu_mask_sz;
|
2019-09-11 20:16:21 +05:30
|
|
|
struct pt_regs regs;
|
2022-04-04 23:51:37 +05:30
|
|
|
struct cpumask cpu_mask;
|
2019-09-11 20:16:21 +05:30
|
|
|
};
|
|
|
|
|
|
2019-09-11 20:25:05 +05:30
|
|
|
struct fadump_memory_range {
|
|
|
|
|
u64 base;
|
|
|
|
|
u64 size;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* fadump memory ranges info */
|
2020-04-20 14:26:09 +05:30
|
|
|
#define RNG_NAME_SZ 16
|
2019-09-11 20:25:05 +05:30
|
|
|
struct fadump_mrange_info {
|
2020-04-20 14:26:09 +05:30
|
|
|
char name[RNG_NAME_SZ];
|
2019-09-11 20:25:05 +05:30
|
|
|
struct fadump_memory_range *mem_ranges;
|
|
|
|
|
u32 mem_ranges_sz;
|
|
|
|
|
u32 mem_range_cnt;
|
|
|
|
|
u32 max_mem_ranges;
|
2020-04-20 14:26:09 +05:30
|
|
|
bool is_static;
|
2019-09-11 20:16:21 +05:30
|
|
|
};
|
|
|
|
|
|
2019-09-11 20:18:40 +05:30
|
|
|
/* Platform specific callback functions */
|
|
|
|
|
struct fadump_ops;
|
|
|
|
|
|
2019-09-11 20:16:21 +05:30
|
|
|
/* Firmware-assisted dump configuration details. */
|
|
|
|
|
struct fw_dump {
|
|
|
|
|
unsigned long reserve_dump_area_start;
|
|
|
|
|
unsigned long reserve_dump_area_size;
|
|
|
|
|
/* cmd line option during boot */
|
|
|
|
|
unsigned long reserve_bootvar;
|
|
|
|
|
|
|
|
|
|
unsigned long cpu_state_data_size;
|
2019-09-11 20:24:50 +05:30
|
|
|
u64 cpu_state_dest_vaddr;
|
|
|
|
|
u32 cpu_state_data_version;
|
|
|
|
|
u32 cpu_state_entry_size;
|
|
|
|
|
|
2019-09-11 20:16:21 +05:30
|
|
|
unsigned long hpte_region_size;
|
2019-09-11 20:18:57 +05:30
|
|
|
|
2019-09-11 20:16:21 +05:30
|
|
|
unsigned long boot_memory_size;
|
2019-09-11 20:18:57 +05:30
|
|
|
u64 boot_mem_dest_addr;
|
2019-09-11 20:27:39 +05:30
|
|
|
u64 boot_mem_addr[FADUMP_MAX_MEM_REGS];
|
|
|
|
|
u64 boot_mem_sz[FADUMP_MAX_MEM_REGS];
|
|
|
|
|
u64 boot_mem_top;
|
|
|
|
|
u64 boot_mem_regs_cnt;
|
2019-09-11 20:16:21 +05:30
|
|
|
|
|
|
|
|
unsigned long fadumphdr_addr;
|
powerpc: make fadump resilient with memory add/remove events
Due to changes in memory resources caused by either memory hotplug or
online/offline events, the elfcorehdr, which describes the CPUs and
memory of the crashed kernel to the kernel that collects the dump (known
as second/fadump kernel), becomes outdated. Consequently, attempting
dump collection with an outdated elfcorehdr can lead to failed or
inaccurate dump collection.
Memory hotplug or online/offline events is referred as memory add/remove
events in reset of the commit message.
The current solution to address the aforementioned issue is as follows:
Monitor memory add/remove events in userspace using udev rules, and
re-register fadump whenever there are changes in memory resources. This
leads to the creation of a new elfcorehdr with updated system memory
information.
There are several notable issues associated with re-registering fadump
for every memory add/remove events.
1. Bulk memory add/remove events with udev-based fadump re-registration
can lead to race conditions and, more importantly, it creates a wide
window during which fadump is inactive until all memory add/remove
events are settled.
2. Re-registering fadump for every memory add/remove event is
inefficient.
3. The memory for elfcorehdr is allocated based on the memblock regions
available during early boot and remains fixed thereafter. However, if
elfcorehdr is later recreated with additional memblock regions, its
size will increase, potentially leading to memory corruption.
Address the aforementioned challenges by shifting the creation of
elfcorehdr from the first kernel (also referred as the crashed kernel),
where it was created and frequently recreated for every memory
add/remove event, to the fadump kernel. As a result, the elfcorehdr only
needs to be created once, thus eliminating the necessity to re-register
fadump during memory add/remove events.
At present, the first kernel prepares fadump header and stores it in the
fadump reserved area. The fadump header includes the start address of
the elfcorehdr, crashing CPU details, and other relevant information. In
the event of a crash in the first kernel, the second/fadump boots and
accesses the fadump header prepared by the first kernel. It then
performs the following steps in a platform-specific function
[rtas|opal]_fadump_process:
1. Sanity check for fadump header
2. Update CPU notes in elfcorehdr
Along with the above, update the setup_fadump()/fadump.c to create
elfcorehdr and set its address to the global variable elfcorehdr_addr
for the vmcore module to process it in the second/fadump kernel.
Section below outlines the information required to create the elfcorehdr
and the changes made to make it available to the fadump kernel if it's
not already.
To create elfcorehdr, the following crashed kernel information is
required: CPU notes, vmcoreinfo, and memory ranges.
At present, the CPU notes are already prepared in the fadump kernel, so
no changes are needed in that regard. The fadump kernel has access to
all crashed kernel memory regions, including boot memory regions that
are relocated by firmware to fadump reserved areas, so no changes for
that either. However, it is necessary to add new members to the fadump
header, i.e., the 'fadump_crash_info_header' structure, in order to pass
the crashed kernel's vmcoreinfo address and its size to fadump kernel.
In addition to the vmcoreinfo address and size, there are a few other
attributes also added to the fadump_crash_info_header structure.
1. version:
It stores the fadump header version, which is currently set to 1.
This provides flexibility to update the fadump crash info header in
the future without changing the magic number. For each change in the
fadump header, the version will be increased. This will help the
updated kernel determine how to handle kernel dumps from older
kernels. The magic number remains relevant for checking fadump header
corruption.
2. pt_regs_sz/cpu_mask_sz:
Store size of pt_regs and cpu_mask structure of first kernel. These
attributes are used to prevent dump processing if the sizes of
pt_regs or cpu_mask structure differ between the first and fadump
kernels.
Note: if either first/crashed kernel or second/fadump kernel do not have
the changes introduced here then kernel fail to collect the dump and
prints relevant error message on the console.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240422195932.1583833-2-sourabhjain@linux.ibm.com
2024-04-23 01:29:30 +05:30
|
|
|
u64 elfcorehdr_addr;
|
|
|
|
|
u64 elfcorehdr_size;
|
2019-09-11 20:16:36 +05:30
|
|
|
unsigned long cpu_notes_buf_vaddr;
|
2019-09-11 20:16:21 +05:30
|
|
|
unsigned long cpu_notes_buf_size;
|
|
|
|
|
|
2024-05-09 17:27:54 +05:30
|
|
|
unsigned long param_area;
|
|
|
|
|
|
2019-09-11 20:27:39 +05:30
|
|
|
/*
|
|
|
|
|
* Maximum size supported by firmware to copy from source to
|
|
|
|
|
* destination address per entry.
|
|
|
|
|
*/
|
|
|
|
|
u64 max_copy_size;
|
2019-09-11 20:20:57 +05:30
|
|
|
u64 kernel_metadata;
|
|
|
|
|
|
2019-09-11 20:16:21 +05:30
|
|
|
int ibm_configure_kernel_dump;
|
|
|
|
|
|
|
|
|
|
unsigned long fadump_enabled:1;
|
|
|
|
|
unsigned long fadump_supported:1;
|
|
|
|
|
unsigned long dump_active:1;
|
|
|
|
|
unsigned long dump_registered:1;
|
|
|
|
|
unsigned long nocma:1;
|
2024-05-09 17:27:54 +05:30
|
|
|
unsigned long param_area_supported:1;
|
2019-09-11 20:18:40 +05:30
|
|
|
|
|
|
|
|
struct fadump_ops *ops;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct fadump_ops {
|
|
|
|
|
u64 (*fadump_init_mem_struct)(struct fw_dump *fadump_conf);
|
2019-09-11 20:20:57 +05:30
|
|
|
u64 (*fadump_get_metadata_size)(void);
|
|
|
|
|
int (*fadump_setup_metadata)(struct fw_dump *fadump_conf);
|
2019-09-11 20:26:59 +05:30
|
|
|
u64 (*fadump_get_bootmem_min)(void);
|
2019-09-11 20:18:40 +05:30
|
|
|
int (*fadump_register)(struct fw_dump *fadump_conf);
|
|
|
|
|
int (*fadump_unregister)(struct fw_dump *fadump_conf);
|
|
|
|
|
int (*fadump_invalidate)(struct fw_dump *fadump_conf);
|
2019-09-11 20:21:16 +05:30
|
|
|
void (*fadump_cleanup)(struct fw_dump *fadump_conf);
|
2019-09-11 20:18:40 +05:30
|
|
|
int (*fadump_process)(struct fw_dump *fadump_conf);
|
|
|
|
|
void (*fadump_region_show)(struct fw_dump *fadump_conf,
|
|
|
|
|
struct seq_file *m);
|
|
|
|
|
void (*fadump_trigger)(struct fadump_crash_info_header *fdh,
|
|
|
|
|
const char *msg);
|
2024-05-09 17:27:53 +05:30
|
|
|
int (*fadump_max_boot_mem_rgns)(void);
|
2019-09-11 20:16:21 +05:30
|
|
|
};
|
|
|
|
|
|
2019-09-11 20:16:52 +05:30
|
|
|
/* Helper functions */
|
2021-12-16 17:00:16 -05:00
|
|
|
s32 __init fadump_setup_cpu_notes_buf(u32 num_cpus);
|
2019-09-11 20:16:52 +05:30
|
|
|
void fadump_free_cpu_notes_buf(void);
|
2021-12-16 17:00:16 -05:00
|
|
|
u32 *__init fadump_regs_to_elf_notes(u32 *buf, struct pt_regs *regs);
|
|
|
|
|
void __init fadump_update_elfcore_header(char *bufp);
|
2019-09-11 20:16:52 +05:30
|
|
|
bool is_fadump_reserved_mem_contiguous(void);
|
|
|
|
|
|
2019-09-11 20:26:03 +05:30
|
|
|
#else /* !CONFIG_PRESERVE_FA_DUMP */
|
|
|
|
|
|
|
|
|
|
/* Firmware-assisted dump configuration details. */
|
|
|
|
|
struct fw_dump {
|
|
|
|
|
u64 boot_mem_top;
|
|
|
|
|
u64 dump_active;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif /* CONFIG_PRESERVE_FA_DUMP */
|
|
|
|
|
|
2019-09-11 20:18:40 +05:30
|
|
|
#ifdef CONFIG_PPC_PSERIES
|
|
|
|
|
extern void rtas_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node);
|
|
|
|
|
#else
|
|
|
|
|
static inline void
|
|
|
|
|
rtas_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node) { }
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-09-11 20:20:26 +05:30
|
|
|
#ifdef CONFIG_PPC_POWERNV
|
|
|
|
|
extern void opal_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node);
|
|
|
|
|
#else
|
|
|
|
|
static inline void
|
|
|
|
|
opal_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node) { }
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-09-11 20:16:21 +05:30
|
|
|
#endif /* _ASM_POWERPC_FADUMP_INTERNAL_H */
|