This patchset did two things:
a. add a new document for vmcoreinfo
This document lists some variables that export to vmcoreinfo, and briefly
describles what these variables indicate. It should be instructive for
many people who do not know the vmcoreinfo, and it also normalizes the
exported variable as a convention between kernel and use-space.
b. export the value of sme mask to vmcoreinfo
For AMD machine with SME feature, makedumpfile tools need to know whether
the crash kernel was encrypted or not. If SME is enabled in the first
kernel, the crash kernel's page table(pgd/pud/pmd/pte) contains the
memory encryption mask, so need to remove the sme mask to obtain the true
physical address.
Changes since v1:
1. No need to export a kernel-internal mask to userspace, so copy the
value of sme_me_mask to a local variable 'sme_mask' and write the value
of sme_mask to vmcoreinfo.
2. Add comment for the code.
3. Improve the patch log.
4. Add the vmcoreinfo documentation.
Changes since v2:
1. Improve the vmcoreinfo document, add more descripts for these
variables exported.
2. Fix spelling errors in the document.
Changes since v3:
1. Still improve the vmcoreinfo document, and make it become more
clear and easy to read.
2. Move sme_mask comments in the code to the vmcoreinfo document.
3. Improve patch log.
Changes since v4:
1. Remove a command that dumping the VMCOREINFO contents from this
document.
2. Merge the 'PG_buddy' and 'PG_offline' into the PG_* flag in this
document.
3. Correct some of the mistakes in this document.
*** BLURB HERE ***
Lianbo Jiang (2):
kdump: add the vmcoreinfo documentation
kdump,vmcoreinfo: Export the value of sme mask to vmcoreinfo
Documentation/kdump/vmcoreinfo.txt | 500 +++++++++++++++++++++++++++++
arch/x86/kernel/machine_kexec_64.c | 3 +
2 files changed, 503 insertions(+)
create mode 100644 Documentation/kdump/vmcoreinfo.txt
--
2.17.1
This document lists some variables that export to vmcoreinfo, and briefly
describles what these variables indicate. It should be instructive for
many people who do not know the vmcoreinfo, and it also normalizes the
exported variables as a convention between kernel and use-space.
Suggested-by: Borislav Petkov <[email protected]>
Signed-off-by: Lianbo Jiang <[email protected]>
---
Documentation/kdump/vmcoreinfo.txt | 500 +++++++++++++++++++++++++++++
1 file changed, 500 insertions(+)
create mode 100644 Documentation/kdump/vmcoreinfo.txt
diff --git a/Documentation/kdump/vmcoreinfo.txt b/Documentation/kdump/vmcoreinfo.txt
new file mode 100644
index 000000000000..8e444586b87b
--- /dev/null
+++ b/Documentation/kdump/vmcoreinfo.txt
@@ -0,0 +1,500 @@
+================================================================
+ VMCOREINFO
+================================================================
+
+=======================
+What is the VMCOREINFO?
+=======================
+
+VMCOREINFO is a special ELF note section. It contains various
+information from the kernel like structure size, page size, symbol
+values, field offsets, etc. These data are packed into an ELF note
+section and used by user-space tools like crash and makedumpfile to
+analyze a kernel's memory layout.
+
+================
+Common variables
+================
+
+init_uts_ns.name.release
+------------------------
+
+The version of the Linux kernel. Used to find the corresponding source
+code from which the kernel has been built.
+
+PAGE_SIZE
+---------
+
+The size of a page. It is the smallest unit of data for memory
+management in kernel. It is usually 4096 bytes and a page is aligned
+on 4096 bytes. Used for computing page addresses.
+
+init_uts_ns
+-----------
+
+This is the UTS namespace, which is used to isolate two specific
+elements of the system that relate to the uname(2) system call. The UTS
+namespace is named after the data structure used to store information
+returned by the uname(2) system call.
+
+User-space tools can get the kernel name, host name, kernel release
+number, kernel version, architecture name and OS type from it.
+
+node_online_map
+---------------
+
+An array node_states[N_ONLINE] which represents the set of online node
+in a system, one bit position per node number. Used to keep track of
+which nodes are in the system and online.
+
+swapper_pg_dir
+-------------
+
+The global page directory pointer of the kernel. Used to translate
+virtual to physical addresses.
+
+_stext
+------
+
+Defines the beginning of the text section. In general, _stext indicates
+the kernel start address. Used to convert a virtual address from the
+direct kernel map to a physical address.
+
+vmap_area_list
+--------------
+
+Stores the virtual area list. makedumpfile can get the vmalloc start
+value from this variable. This value is necessary for vmalloc translation.
+
+mem_map
+-------
+
+Physical addresses are translated to struct pages by treating them as
+an index into the mem_map array. Right-shifting a physical address
+PAGE_SHIFT bits converts it into a page frame number which is an index
+into that mem_map array.
+
+Used to map an address to the corresponding struct page.
+
+contig_page_data
+----------------
+
+Makedumpfile can get the pglist_data structure from this symbol, which
+is used to describe the memory layout.
+
+User-space tools use this to exclude free pages when dumping memory.
+
+mem_section|(mem_section, NR_SECTION_ROOTS)|(mem_section, section_mem_map)
+--------------------------------------------------------------------------
+
+The address of the mem_section array, its length, structure size, and
+the section_mem_map offset.
+
+It exists in the sparse memory mapping model, and it is also somewhat
+similar to the mem_map variable, both of them are used to translate an
+address.
+
+page
+----
+
+The size of a page structure. struct page is an important data structure
+and it is widely used to compute the contiguous memory.
+
+pglist_data
+-----------
+
+The size of a pglist_data structure. This value will be used to check
+if the pglist_data structure is valid. It is also used for checking the
+memory type.
+
+zone
+----
+
+The size of a zone structure. This value is often used to check if the
+zone structure has been found. It is also used for excluding free pages.
+
+free_area
+---------
+
+The size of a free_area structure. It indicates whether the free_area
+structure is valid or not. Useful for excluding free pages.
+
+list_head
+---------
+
+The size of a list_head structure. Used when iterating lists in a
+post-mortem analysis session.
+
+nodemask_t
+----------
+
+The size of a nodemask_t type. Used to compute the number of online
+nodes.
+
+(page, flags|_refcount|mapping|lru|_mapcount|private|compound_dtor|
+ compound_order|compound_head)
+-------------------------------------------------------------------
+
+User-space tools can compute their values based on the offset of these
+variables. The variables are helpful to exclude unnecessary pages.
+
+(pglist_data, node_zones|nr_zones|node_mem_map|node_start_pfn|node_
+ spanned_pages|node_id)
+-------------------------------------------------------------------
+
+On NUMA machines, each NUMA node has a pg_data_t to describe its memory
+layout. On UMA machines there is a single pglist_data which describes the
+whole memory.
+
+These values are used to check the memory type, and they are also helpful
+to compute the virtual address for memory map.
+
+(zone, free_area|vm_stat|spanned_pages)
+---------------------------------------
+
+Each node is divided into a number of blocks called zones which
+represent ranges within memory. A zone is described by a structure zone.
+Each zone type is suitable for a different type of usage.
+
+User-space tools can compute required values based on the offset of these
+variables.
+
+(free_area, free_list)
+----------------------
+
+Offset of the free_list's member. This value is used to compute the number
+of free pages.
+
+Each zone has a free_area structure array called free_area[MAX_ORDER].
+The fields in this structure are simple, the free_list represents a linked
+list of free page blocks.
+
+(list_head, next|prev)
+----------------------
+
+Offsets of the list_head's members. list_head is used to define a
+circular linked list. User-space tools need these in order to traverse
+lists.
+
+(vmap_area, va_start|list)
+--------------------------
+
+Offsets of the vmap_area's members. They indicate the vmalloc layer
+information. Makedumpfile gets the start address of the vmalloc region.
+
+(zone.free_area, MAX_ORDER)
+---------------------------
+
+It indicates the maximum number of the array free_area. This macro is
+used by the zone buddy allocator. User-space tools use this value to
+iterate the free_area.
+
+log_buf
+-------
+
+Console output is written to the ring buffer log_buf at index
+log_first_idx. Used to get the kernel log.
+
+log_buf_len
+-----------
+
+Length of a log_buf. Used to read the number of strings from the
+log_buf.
+
+log_first_idx
+-------------
+
+Index of the first record stored in the buffer log_buf. Used by
+user-space tools to read the strings in the log_buf.
+
+clear_idx
+---------
+
+The index that the next printk() record to read after the last clear
+command. It indicates the first record after the last SYSLOG_ACTION
+_CLEAR, like issued by 'dmesg -c'. Used by user-space tools to dump
+the dmesg log.
+
+log_next_idx
+------------
+
+The index of the next record to store in the buffer log_buf. Used to
+compute the index of the current string position.
+
+printk_log
+----------
+
+The size of a structure printk_log. Used to compute the size of
+messages, and extract dmesg log. It can output human readable text.
+Encapsulate header information for log_buf, such as timestamp, syslog
+level, etc.
+
+(printk_log, ts_nsec|len|text_len|dict_len)
+-------------------------------------------
+
+It represents field offsets in struct printk_log. User space tools can
+parse it and check whether the values of printk_log's members have been
+changed.
+
+(free_area.free_list, MIGRATE_TYPES)
+------------------------------------
+
+The number of migrate types for pages. The free_list is divided into
+the array, it needs to know the number of the array when makedumpfile
+computes the number of free pages.
+
+NR_FREE_PAGES
+-------------
+
+On linux-2.6.21 or later, the number of free_pages is in
+vm_stat[NR_FREE_PAGES]. Used to get the number of free pages.
+
+PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision
+|PG_head_mask|PAGE_BUDDY_MAPCOUNT_VALUE(~PG_buddy)
+|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_offline)
+-----------------------------------------------------------------
+
+Page attributes. These flags are used to filter various unnecessary
+pages.
+
+HUGETLB_PAGE_DTOR
+-----------------
+
+The HUGETLB_PAGE_DTOR flag denotes hugetlbfs pages. Makedumpfile
+excludes these pages.
+
+======
+x86_64
+======
+
+phys_base
+---------
+
+Used to convert the virtual address of an exported kernel symbol to its
+physical address.
+
+init_top_pgt
+------------
+
+Used to walk through the whole page table and convert virtual addresses
+to physical addresses. The init_top_pgt is somewhat similar to the
+swapper_pg_dir, but it is only used in x86_64.
+
+pgtable_l5_enabled
+------------------
+
+User-space tools need to know whether the crash kernel was in 5-level
+paging mode.
+
+node_data
+---------
+
+This is a struct pglist_data array and stores all numa nodes
+information. Makedumpfile gets the pglist_data structure from it.
+
+(node_data, MAX_NUMNODES)
+-------------------------
+
+The maximum number of the nodes in system.
+
+KERNELOFFSET
+------------
+
+The kernel randomization offset. Used to compute the page offset. If
+KASLR is disabled, this value is zero.
+
+KERNEL_IMAGE_SIZE
+-----------------
+
+Currently unused by Makedumpfile. Used to compute the module virtual
+address by Crash.
+
+sme_mask
+--------
+
+For AMD machine with SME feature, it indicates the secure memory
+encryption mask. Makedumpfile tools need to know whether the crash
+kernel was encrypted. If SME is enabled in the first kernel, the crash
+kernel's page table (pgd/pud/pmd/pte) contains the memory encryption
+mask and this is used to remove the SME mask to obtain the true physical
+address.
+
+Currently, the sme_mask stores the value of sme_me_mask(bit 47). If need,
+the bit(sme_mask) might be redefined in the future, but the bit 63 will
+be reserved.
+
+For example:
+[ misc ][ enc bit ][ other misc SME info ]
+0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_..._0000
+63 59 55 51 47 43 39 35 31 27 ... 3
+
+======
+x86_32
+======
+
+X86_PAE
+-------
+
+Denotes whether physical address extensions are enabled. It has the cost
+of more page table lookup overhead, and also consumes more page table
+space per process. Used to check whether PAE was enabled in the crash
+kernel when converting virtual addresses to physical addresses.
+
+====
+ia64
+====
+
+pgdat_list|(pgdat_list, MAX_NUMNODES)
+-------------------------------------
+
+pg_data_t array storing all numa nodes information. MAX_NUMNODES
+indicates the number of the nodes.
+
+node_memblk|(node_memblk, NR_NODE_MEMBLKS)
+------------------------------------------
+
+List of node memory chunks. Filled when parsing SRAT table to obtain
+information about memory nodes. NR_NODE_MEMBLKS indicates the number
+of node memory chunks.
+
+These values are used to compute the number of nodes in the crash kernel.
+
+node_memblk_s|(node_memblk_s, start_paddr)|(node_memblk_s, size)
+----------------------------------------------------------------
+
+The size of a struct node_memblk_s and the offsets of the
+node_memblk_s's members. Used to compute the number of nodes.
+
+PGTABLE_3|PGTABLE_4
+-------------------
+
+User-space tools need to know whether the crash kernel was in 3-level or
+4-level paging mode. Used to distinguish the page table.
+
+=====
+ARM64
+=====
+
+VA_BITS
+-------
+
+The maximum number of bits for virtual addresses. Used to compute the
+virtual memory ranges.
+
+kimage_voffset
+--------------
+
+The offset between the kernel virtual and physical mappings. Used to
+translate virtual to physical addresses.
+
+PHYS_OFFSET
+-----------
+
+Indicates the physical address of the start of memory. Similar to
+kimage_voffset, which is used to translate virtual address to physical
+address.
+
+KERNELOFFSET
+------------
+
+The kernel randomization offset. Used to compute the page offset. If
+KASLR is disabled, this value is zero.
+
+====
+arm
+====
+
+ARM_LPAE
+--------
+
+It indicates whether the crash kernel supports large physical address
+extensions. Used to translate virtual address to physical address.
+
+====
+s390
+====
+
+lowcore_ptr
+----------
+
+An array with a pointer to the lowcore of every CPU. Used to print the
+psw and all registers information.
+
+high_memory
+-----------
+
+Used to get the vmalloc_start address from the high_memory symbol.
+
+(lowcore_ptr, NR_CPUS)
+----------------------
+
+The maximum number of CPUs.
+
+=======
+powerpc
+=======
+
+
+node_data|(node_data, MAX_NUMNODES)
+-----------------------------------
+
+See above.
+
+contig_page_data
+----------------
+
+See above.
+
+vmemmap_list
+------------
+
+The vmemmap_list maintains the entire vmemmap physical mapping. It can
+get vmemmap list count and populate vmemmap regions info. If the vmemmap
+address translation information is stored in the crash kernel, it helps
+to translate vmemmap kernel virtual addresses.
+
+mmu_vmemmap_psize
+-----------------
+
+The size of a page. Used to translate address to physical addresses.
+
+mmu_psize_defs
+--------------
+
+Page size definitions, i.e. 4k, 64k, or 16M.
+
+Used to make vtop translations.
+
+vmemmap_backing|(vmemmap_backing, list)|(vmemmap_backing, phys)|
+(vmemmap_backing, virt_addr)
+----------------------------------------------------------------
+
+The vmemmap virtual address space management does not have a traditional
+page table to track which virtual struct pages are backed by physical
+mapping. The virtual to physical mappings are tracked in a simple linked
+list format.
+
+User-space tools need to know the offset of list, phys and virt_addr
+when computing the count of vmemmap regions.
+
+mmu_psize_def|(mmu_psize_def, shift)
+------------------------------------
+
+The size of a struct mmu_psize_def and the offset of mmu_psize_def's
+member.
+
+Used in vtop translations.
+
+==
+sh
+==
+
+node_data|(node_data, MAX_NUMNODES)
+-----------------------------------
+
+See above.
+
+X2TLB
+-----
+
+Indicates whether the crash kernel enables SH extended mode.
--
2.17.1
For AMD machine with SME feature, makedumpfile tools need to know
whether the crash kernel was encrypted or not. If SME is enabled
in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
contains the memory encryption mask, so need to remove the sme mask
to obtain the true physical address.
Signed-off-by: Lianbo Jiang <[email protected]>
---
arch/x86/kernel/machine_kexec_64.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 4c8acdfdc5a7..bc4108096b18 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -352,10 +352,13 @@ void machine_kexec(struct kimage *image)
void arch_crash_save_vmcoreinfo(void)
{
+ u64 sme_mask = sme_me_mask;
+
VMCOREINFO_NUMBER(phys_base);
VMCOREINFO_SYMBOL(init_top_pgt);
vmcoreinfo_append_str("NUMBER(pgtable_l5_enabled)=%d\n",
pgtable_l5_enabled());
+ VMCOREINFO_NUMBER(sme_mask);
#ifdef CONFIG_NUMA
VMCOREINFO_SYMBOL(node_data);
--
2.17.1
On 01/07/19 at 09:47am, Lianbo Jiang wrote:
> For AMD machine with SME feature, makedumpfile tools need to know
> whether the crash kernel was encrypted or not. If SME is enabled
^ crashed
> in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
^ crashed
> contains the memory encryption mask, so need to remove the sme mask
"makedumpfile needs" or
in makedumpfile need to remove...
> to obtain the true physical address.
>
> Signed-off-by: Lianbo Jiang <[email protected]>
> ---
> arch/x86/kernel/machine_kexec_64.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
> index 4c8acdfdc5a7..bc4108096b18 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -352,10 +352,13 @@ void machine_kexec(struct kimage *image)
>
> void arch_crash_save_vmcoreinfo(void)
> {
> + u64 sme_mask = sme_me_mask;
> +
> VMCOREINFO_NUMBER(phys_base);
> VMCOREINFO_SYMBOL(init_top_pgt);
> vmcoreinfo_append_str("NUMBER(pgtable_l5_enabled)=%d\n",
> pgtable_l5_enabled());
> + VMCOREINFO_NUMBER(sme_mask);
>
> #ifdef CONFIG_NUMA
> VMCOREINFO_SYMBOL(node_data);
> --
> 2.17.1
>
Hi,
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Lianbo Jiang
> Sent: Monday, January 7, 2019 10:48 AM
> To: [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]
> Subject: [PATCH 1/2 v5] kdump: add the vmcoreinfo documentation
>
> This document lists some variables that export to vmcoreinfo, and briefly
> describles what these variables indicate. It should be instructive for
> many people who do not know the vmcoreinfo, and it also normalizes the
I agree to this part, but
> exported variables as a convention between kernel and use-space.
I don't agree to this part.
The meaning of each symbol is decided by each feature in the kernel,
not by vmcoreinfo. I suspect anyone mistakenly understand this document is
ABI enforcing each symbol works as described. We can change symbols and
their meaning regardless of this document.
Oh, I found this topic has already been discussed at v3, and
you removed "ABI" in the patch description at v4.
But it seems still confusing to me.
I think the explicit description saying that this is for user-land tools,
they treats each symbol as described,
and the document never affect implementation of each kernel components,
is necessary in e.g. "Purpose of this document" section?
>
> Suggested-by: Borislav Petkov <[email protected]>
> Signed-off-by: Lianbo Jiang <[email protected]>
> ---
> Documentation/kdump/vmcoreinfo.txt | 500 +++++++++++++++++++++++++++++
> 1 file changed, 500 insertions(+)
> create mode 100644 Documentation/kdump/vmcoreinfo.txt
>
> diff --git a/Documentation/kdump/vmcoreinfo.txt
> b/Documentation/kdump/vmcoreinfo.txt
> new file mode 100644
> index 000000000000..8e444586b87b
> --- /dev/null
> +++ b/Documentation/kdump/vmcoreinfo.txt
> @@ -0,0 +1,500 @@
> +================================================================
> + VMCOREINFO
> +================================================================
> +
> +=======================
> +What is the VMCOREINFO?
> +=======================
> +
> +VMCOREINFO is a special ELF note section. It contains various
> +information from the kernel like structure size, page size, symbol
> +values, field offsets, etc. These data are packed into an ELF note
> +section and used by user-space tools like crash and makedumpfile to
> +analyze a kernel's memory layout.
> +
> +================
> +Common variables
> +================
> +
> +init_uts_ns.name.release
> +------------------------
> +
> +The version of the Linux kernel. Used to find the corresponding source
> +code from which the kernel has been built.
> +
> +PAGE_SIZE
> +---------
> +
> +The size of a page. It is the smallest unit of data for memory
> +management in kernel. It is usually 4096 bytes and a page is aligned
> +on 4096 bytes. Used for computing page addresses.
> +
> +init_uts_ns
> +-----------
> +
> +This is the UTS namespace, which is used to isolate two specific
> +elements of the system that relate to the uname(2) system call. The UTS
> +namespace is named after the data structure used to store information
> +returned by the uname(2) system call.
> +
> +User-space tools can get the kernel name, host name, kernel release
> +number, kernel version, architecture name and OS type from it.
> +
> +node_online_map
> +---------------
> +
> +An array node_states[N_ONLINE] which represents the set of online node
> +in a system, one bit position per node number. Used to keep track of
> +which nodes are in the system and online.
> +
> +swapper_pg_dir
> +-------------
> +
> +The global page directory pointer of the kernel. Used to translate
> +virtual to physical addresses.
> +
> +_stext
> +------
> +
> +Defines the beginning of the text section. In general, _stext indicates
> +the kernel start address. Used to convert a virtual address from the
> +direct kernel map to a physical address.
> +
> +vmap_area_list
> +--------------
> +
> +Stores the virtual area list. makedumpfile can get the vmalloc start
> +value from this variable. This value is necessary for vmalloc translation.
> +
> +mem_map
> +-------
> +
> +Physical addresses are translated to struct pages by treating them as
> +an index into the mem_map array. Right-shifting a physical address
> +PAGE_SHIFT bits converts it into a page frame number which is an index
> +into that mem_map array.
> +
> +Used to map an address to the corresponding struct page.
> +
> +contig_page_data
> +----------------
> +
> +Makedumpfile can get the pglist_data structure from this symbol, which
> +is used to describe the memory layout.
> +
> +User-space tools use this to exclude free pages when dumping memory.
> +
> +mem_section|(mem_section, NR_SECTION_ROOTS)|(mem_section, section_mem_map)
> +-------------------------------------------------------------------------
> -
> +
> +The address of the mem_section array, its length, structure size, and
> +the section_mem_map offset.
> +
> +It exists in the sparse memory mapping model, and it is also somewhat
> +similar to the mem_map variable, both of them are used to translate an
> +address.
> +
> +page
> +----
> +
> +The size of a page structure. struct page is an important data structure
> +and it is widely used to compute the contiguous memory.
> +
> +pglist_data
> +-----------
> +
> +The size of a pglist_data structure. This value will be used to check
> +if the pglist_data structure is valid. It is also used for checking the
> +memory type.
> +
> +zone
> +----
> +
> +The size of a zone structure. This value is often used to check if the
> +zone structure has been found. It is also used for excluding free pages.
> +
> +free_area
> +---------
> +
> +The size of a free_area structure. It indicates whether the free_area
> +structure is valid or not. Useful for excluding free pages.
> +
> +list_head
> +---------
> +
> +The size of a list_head structure. Used when iterating lists in a
> +post-mortem analysis session.
> +
> +nodemask_t
> +----------
> +
> +The size of a nodemask_t type. Used to compute the number of online
> +nodes.
> +
> +(page, flags|_refcount|mapping|lru|_mapcount|private|compound_dtor|
> + compound_order|compound_head)
> +-------------------------------------------------------------------
> +
> +User-space tools can compute their values based on the offset of these
> +variables. The variables are helpful to exclude unnecessary pages.
> +
> +(pglist_data, node_zones|nr_zones|node_mem_map|node_start_pfn|node_
> + spanned_pages|node_id)
> +-------------------------------------------------------------------
> +
> +On NUMA machines, each NUMA node has a pg_data_t to describe its memory
> +layout. On UMA machines there is a single pglist_data which describes the
> +whole memory.
> +
> +These values are used to check the memory type, and they are also helpful
> +to compute the virtual address for memory map.
> +
> +(zone, free_area|vm_stat|spanned_pages)
> +---------------------------------------
> +
> +Each node is divided into a number of blocks called zones which
> +represent ranges within memory. A zone is described by a structure zone.
> +Each zone type is suitable for a different type of usage.
> +
> +User-space tools can compute required values based on the offset of these
> +variables.
> +
> +(free_area, free_list)
> +----------------------
> +
> +Offset of the free_list's member. This value is used to compute the number
> +of free pages.
> +
> +Each zone has a free_area structure array called free_area[MAX_ORDER].
> +The fields in this structure are simple, the free_list represents a linked
> +list of free page blocks.
> +
> +(list_head, next|prev)
> +----------------------
> +
> +Offsets of the list_head's members. list_head is used to define a
> +circular linked list. User-space tools need these in order to traverse
> +lists.
> +
> +(vmap_area, va_start|list)
> +--------------------------
> +
> +Offsets of the vmap_area's members. They indicate the vmalloc layer
> +information. Makedumpfile gets the start address of the vmalloc region.
> +
> +(zone.free_area, MAX_ORDER)
> +---------------------------
> +
> +It indicates the maximum number of the array free_area. This macro is
> +used by the zone buddy allocator. User-space tools use this value to
> +iterate the free_area.
> +
> +log_buf
> +-------
> +
> +Console output is written to the ring buffer log_buf at index
> +log_first_idx. Used to get the kernel log.
> +
> +log_buf_len
> +-----------
> +
> +Length of a log_buf. Used to read the number of strings from the
> +log_buf.
> +
> +log_first_idx
> +-------------
> +
> +Index of the first record stored in the buffer log_buf. Used by
> +user-space tools to read the strings in the log_buf.
> +
> +clear_idx
> +---------
> +
> +The index that the next printk() record to read after the last clear
> +command. It indicates the first record after the last SYSLOG_ACTION
> +_CLEAR, like issued by 'dmesg -c'. Used by user-space tools to dump
> +the dmesg log.
> +
> +log_next_idx
> +------------
> +
> +The index of the next record to store in the buffer log_buf. Used to
> +compute the index of the current string position.
> +
> +printk_log
> +----------
> +
> +The size of a structure printk_log. Used to compute the size of
> +messages, and extract dmesg log. It can output human readable text.
> +Encapsulate header information for log_buf, such as timestamp, syslog
> +level, etc.
> +
> +(printk_log, ts_nsec|len|text_len|dict_len)
> +-------------------------------------------
> +
> +It represents field offsets in struct printk_log. User space tools can
> +parse it and check whether the values of printk_log's members have been
> +changed.
> +
> +(free_area.free_list, MIGRATE_TYPES)
> +------------------------------------
> +
> +The number of migrate types for pages. The free_list is divided into
> +the array, it needs to know the number of the array when makedumpfile
> +computes the number of free pages.
> +
> +NR_FREE_PAGES
> +-------------
> +
> +On linux-2.6.21 or later, the number of free_pages is in
> +vm_stat[NR_FREE_PAGES]. Used to get the number of free pages.
> +
> +PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision
> +|PG_head_mask|PAGE_BUDDY_MAPCOUNT_VALUE(~PG_buddy)
> +|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_offline)
> +-----------------------------------------------------------------
> +
> +Page attributes. These flags are used to filter various unnecessary
> +pages.
> +
> +HUGETLB_PAGE_DTOR
> +-----------------
> +
> +The HUGETLB_PAGE_DTOR flag denotes hugetlbfs pages. Makedumpfile
> +excludes these pages.
> +
> +======
> +x86_64
> +======
> +
> +phys_base
> +---------
> +
> +Used to convert the virtual address of an exported kernel symbol to its
> +physical address.
> +
> +init_top_pgt
> +------------
> +
> +Used to walk through the whole page table and convert virtual addresses
> +to physical addresses. The init_top_pgt is somewhat similar to the
> +swapper_pg_dir, but it is only used in x86_64.
> +
> +pgtable_l5_enabled
> +------------------
> +
> +User-space tools need to know whether the crash kernel was in 5-level
> +paging mode.
> +
> +node_data
> +---------
> +
> +This is a struct pglist_data array and stores all numa nodes
> +information. Makedumpfile gets the pglist_data structure from it.
> +
> +(node_data, MAX_NUMNODES)
> +-------------------------
> +
> +The maximum number of the nodes in system.
> +
> +KERNELOFFSET
> +------------
> +
> +The kernel randomization offset. Used to compute the page offset. If
> +KASLR is disabled, this value is zero.
> +
> +KERNEL_IMAGE_SIZE
> +-----------------
> +
> +Currently unused by Makedumpfile. Used to compute the module virtual
> +address by Crash.
> +
> +sme_mask
> +--------
> +
> +For AMD machine with SME feature, it indicates the secure memory
> +encryption mask. Makedumpfile tools need to know whether the crash
> +kernel was encrypted. If SME is enabled in the first kernel, the crash
> +kernel's page table (pgd/pud/pmd/pte) contains the memory encryption
> +mask and this is used to remove the SME mask to obtain the true physical
> +address.
> +
> +Currently, the sme_mask stores the value of sme_me_mask(bit 47). If need,
> +the bit(sme_mask) might be redefined in the future, but the bit 63 will
> +be reserved.
> +
> +For example:
> +[ misc ][ enc bit ][ other misc SME info ]
> +0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_..._0000
> +63 59 55 51 47 43 39 35 31 27 ... 3
> +
> +======
> +x86_32
> +======
> +
> +X86_PAE
> +-------
> +
> +Denotes whether physical address extensions are enabled. It has the cost
> +of more page table lookup overhead, and also consumes more page table
> +space per process. Used to check whether PAE was enabled in the crash
> +kernel when converting virtual addresses to physical addresses.
> +
> +====
> +ia64
> +====
> +
> +pgdat_list|(pgdat_list, MAX_NUMNODES)
> +-------------------------------------
> +
> +pg_data_t array storing all numa nodes information. MAX_NUMNODES
> +indicates the number of the nodes.
> +
> +node_memblk|(node_memblk, NR_NODE_MEMBLKS)
> +------------------------------------------
> +
> +List of node memory chunks. Filled when parsing SRAT table to obtain
> +information about memory nodes. NR_NODE_MEMBLKS indicates the number
> +of node memory chunks.
> +
> +These values are used to compute the number of nodes in the crash kernel.
> +
> +node_memblk_s|(node_memblk_s, start_paddr)|(node_memblk_s, size)
> +----------------------------------------------------------------
> +
> +The size of a struct node_memblk_s and the offsets of the
> +node_memblk_s's members. Used to compute the number of nodes.
> +
> +PGTABLE_3|PGTABLE_4
> +-------------------
> +
> +User-space tools need to know whether the crash kernel was in 3-level or
> +4-level paging mode. Used to distinguish the page table.
> +
> +=====
> +ARM64
> +=====
> +
> +VA_BITS
> +-------
> +
> +The maximum number of bits for virtual addresses. Used to compute the
> +virtual memory ranges.
> +
> +kimage_voffset
> +--------------
> +
> +The offset between the kernel virtual and physical mappings. Used to
> +translate virtual to physical addresses.
> +
> +PHYS_OFFSET
> +-----------
> +
> +Indicates the physical address of the start of memory. Similar to
> +kimage_voffset, which is used to translate virtual address to physical
> +address.
> +
> +KERNELOFFSET
> +------------
> +
> +The kernel randomization offset. Used to compute the page offset. If
> +KASLR is disabled, this value is zero.
> +
> +====
> +arm
> +====
> +
> +ARM_LPAE
> +--------
> +
> +It indicates whether the crash kernel supports large physical address
> +extensions. Used to translate virtual address to physical address.
> +
> +====
> +s390
> +====
> +
> +lowcore_ptr
> +----------
> +
> +An array with a pointer to the lowcore of every CPU. Used to print the
> +psw and all registers information.
> +
> +high_memory
> +-----------
> +
> +Used to get the vmalloc_start address from the high_memory symbol.
> +
> +(lowcore_ptr, NR_CPUS)
> +----------------------
> +
> +The maximum number of CPUs.
> +
> +=======
> +powerpc
> +=======
> +
> +
> +node_data|(node_data, MAX_NUMNODES)
> +-----------------------------------
> +
> +See above.
> +
> +contig_page_data
> +----------------
> +
> +See above.
> +
> +vmemmap_list
> +------------
> +
> +The vmemmap_list maintains the entire vmemmap physical mapping. It can
> +get vmemmap list count and populate vmemmap regions info. If the vmemmap
> +address translation information is stored in the crash kernel, it helps
> +to translate vmemmap kernel virtual addresses.
> +
> +mmu_vmemmap_psize
> +-----------------
> +
> +The size of a page. Used to translate address to physical addresses.
> +
> +mmu_psize_defs
> +--------------
> +
> +Page size definitions, i.e. 4k, 64k, or 16M.
> +
> +Used to make vtop translations.
> +
> +vmemmap_backing|(vmemmap_backing, list)|(vmemmap_backing, phys)|
> +(vmemmap_backing, virt_addr)
> +----------------------------------------------------------------
> +
> +The vmemmap virtual address space management does not have a traditional
> +page table to track which virtual struct pages are backed by physical
> +mapping. The virtual to physical mappings are tracked in a simple linked
> +list format.
> +
> +User-space tools need to know the offset of list, phys and virt_addr
> +when computing the count of vmemmap regions.
> +
> +mmu_psize_def|(mmu_psize_def, shift)
> +------------------------------------
> +
> +The size of a struct mmu_psize_def and the offset of mmu_psize_def's
> +member.
> +
> +Used in vtop translations.
> +
> +==
> +sh
> +==
> +
> +node_data|(node_data, MAX_NUMNODES)
> +-----------------------------------
> +
> +See above.
> +
> +X2TLB
> +-----
> +
> +Indicates whether the crash kernel enables SH extended mode.
> --
> 2.17.1
>
$B:_(B 2019$BG/(B01$B7n(B07$BF|(B 15:55, Hatayama, Daisuke $B<LF;(B:
> Hi,
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Lianbo Jiang
>> Sent: Monday, January 7, 2019 10:48 AM
>> To: [email protected]
>> Cc: [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]
>> Subject: [PATCH 1/2 v5] kdump: add the vmcoreinfo documentation
>>
>> This document lists some variables that export to vmcoreinfo, and briefly
>> describles what these variables indicate. It should be instructive for
>> many people who do not know the vmcoreinfo, and it also normalizes the
>
> I agree to this part, but
>
>> exported variables as a convention between kernel and use-space.
>
> I don't agree to this part.
>
> The meaning of each symbol is decided by each feature in the kernel,
> not by vmcoreinfo. I suspect anyone mistakenly understand this document is
> ABI enforcing each symbol works as described. We can change symbols and
> their meaning regardless of this document.
>
> Oh, I found this topic has already been discussed at v3, and
> you removed "ABI" in the patch description at v4.
>
> But it seems still confusing to me.
> I think the explicit description saying that this is for user-land tools,
> they treats each symbol as described,
> and the document never affect implementation of each kernel components,
> is necessary in e.g. "Purpose of this document" section?
>
Thanks for your advice.
If this part could make the document become a rope tied around our necks, i would
like to remove this part from the patch log in next post.
Regards,
Lianbo
>>
>> Suggested-by: Borislav Petkov <[email protected]>
>> Signed-off-by: Lianbo Jiang <[email protected]>
>> ---
>> Documentation/kdump/vmcoreinfo.txt | 500 +++++++++++++++++++++++++++++
>> 1 file changed, 500 insertions(+)
>> create mode 100644 Documentation/kdump/vmcoreinfo.txt
>>
>> diff --git a/Documentation/kdump/vmcoreinfo.txt
>> b/Documentation/kdump/vmcoreinfo.txt
>> new file mode 100644
>> index 000000000000..8e444586b87b
>> --- /dev/null
>> +++ b/Documentation/kdump/vmcoreinfo.txt
>> @@ -0,0 +1,500 @@
>> +================================================================
>> + VMCOREINFO
>> +================================================================
>> +
>> +=======================
>> +What is the VMCOREINFO?
>> +=======================
>> +
>> +VMCOREINFO is a special ELF note section. It contains various
>> +information from the kernel like structure size, page size, symbol
>> +values, field offsets, etc. These data are packed into an ELF note
>> +section and used by user-space tools like crash and makedumpfile to
>> +analyze a kernel's memory layout.
>> +
>> +================
>> +Common variables
>> +================
>> +
>> +init_uts_ns.name.release
>> +------------------------
>> +
>> +The version of the Linux kernel. Used to find the corresponding source
>> +code from which the kernel has been built.
>> +
>> +PAGE_SIZE
>> +---------
>> +
>> +The size of a page. It is the smallest unit of data for memory
>> +management in kernel. It is usually 4096 bytes and a page is aligned
>> +on 4096 bytes. Used for computing page addresses.
>> +
>> +init_uts_ns
>> +-----------
>> +
>> +This is the UTS namespace, which is used to isolate two specific
>> +elements of the system that relate to the uname(2) system call. The UTS
>> +namespace is named after the data structure used to store information
>> +returned by the uname(2) system call.
>> +
>> +User-space tools can get the kernel name, host name, kernel release
>> +number, kernel version, architecture name and OS type from it.
>> +
>> +node_online_map
>> +---------------
>> +
>> +An array node_states[N_ONLINE] which represents the set of online node
>> +in a system, one bit position per node number. Used to keep track of
>> +which nodes are in the system and online.
>> +
>> +swapper_pg_dir
>> +-------------
>> +
>> +The global page directory pointer of the kernel. Used to translate
>> +virtual to physical addresses.
>> +
>> +_stext
>> +------
>> +
>> +Defines the beginning of the text section. In general, _stext indicates
>> +the kernel start address. Used to convert a virtual address from the
>> +direct kernel map to a physical address.
>> +
>> +vmap_area_list
>> +--------------
>> +
>> +Stores the virtual area list. makedumpfile can get the vmalloc start
>> +value from this variable. This value is necessary for vmalloc translation.
>> +
>> +mem_map
>> +-------
>> +
>> +Physical addresses are translated to struct pages by treating them as
>> +an index into the mem_map array. Right-shifting a physical address
>> +PAGE_SHIFT bits converts it into a page frame number which is an index
>> +into that mem_map array.
>> +
>> +Used to map an address to the corresponding struct page.
>> +
>> +contig_page_data
>> +----------------
>> +
>> +Makedumpfile can get the pglist_data structure from this symbol, which
>> +is used to describe the memory layout.
>> +
>> +User-space tools use this to exclude free pages when dumping memory.
>> +
>> +mem_section|(mem_section, NR_SECTION_ROOTS)|(mem_section, section_mem_map)
>> +-------------------------------------------------------------------------
>> -
>> +
>> +The address of the mem_section array, its length, structure size, and
>> +the section_mem_map offset.
>> +
>> +It exists in the sparse memory mapping model, and it is also somewhat
>> +similar to the mem_map variable, both of them are used to translate an
>> +address.
>> +
>> +page
>> +----
>> +
>> +The size of a page structure. struct page is an important data structure
>> +and it is widely used to compute the contiguous memory.
>> +
>> +pglist_data
>> +-----------
>> +
>> +The size of a pglist_data structure. This value will be used to check
>> +if the pglist_data structure is valid. It is also used for checking the
>> +memory type.
>> +
>> +zone
>> +----
>> +
>> +The size of a zone structure. This value is often used to check if the
>> +zone structure has been found. It is also used for excluding free pages.
>> +
>> +free_area
>> +---------
>> +
>> +The size of a free_area structure. It indicates whether the free_area
>> +structure is valid or not. Useful for excluding free pages.
>> +
>> +list_head
>> +---------
>> +
>> +The size of a list_head structure. Used when iterating lists in a
>> +post-mortem analysis session.
>> +
>> +nodemask_t
>> +----------
>> +
>> +The size of a nodemask_t type. Used to compute the number of online
>> +nodes.
>> +
>> +(page, flags|_refcount|mapping|lru|_mapcount|private|compound_dtor|
>> + compound_order|compound_head)
>> +-------------------------------------------------------------------
>> +
>> +User-space tools can compute their values based on the offset of these
>> +variables. The variables are helpful to exclude unnecessary pages.
>> +
>> +(pglist_data, node_zones|nr_zones|node_mem_map|node_start_pfn|node_
>> + spanned_pages|node_id)
>> +-------------------------------------------------------------------
>> +
>> +On NUMA machines, each NUMA node has a pg_data_t to describe its memory
>> +layout. On UMA machines there is a single pglist_data which describes the
>> +whole memory.
>> +
>> +These values are used to check the memory type, and they are also helpful
>> +to compute the virtual address for memory map.
>> +
>> +(zone, free_area|vm_stat|spanned_pages)
>> +---------------------------------------
>> +
>> +Each node is divided into a number of blocks called zones which
>> +represent ranges within memory. A zone is described by a structure zone.
>> +Each zone type is suitable for a different type of usage.
>> +
>> +User-space tools can compute required values based on the offset of these
>> +variables.
>> +
>> +(free_area, free_list)
>> +----------------------
>> +
>> +Offset of the free_list's member. This value is used to compute the number
>> +of free pages.
>> +
>> +Each zone has a free_area structure array called free_area[MAX_ORDER].
>> +The fields in this structure are simple, the free_list represents a linked
>> +list of free page blocks.
>> +
>> +(list_head, next|prev)
>> +----------------------
>> +
>> +Offsets of the list_head's members. list_head is used to define a
>> +circular linked list. User-space tools need these in order to traverse
>> +lists.
>> +
>> +(vmap_area, va_start|list)
>> +--------------------------
>> +
>> +Offsets of the vmap_area's members. They indicate the vmalloc layer
>> +information. Makedumpfile gets the start address of the vmalloc region.
>> +
>> +(zone.free_area, MAX_ORDER)
>> +---------------------------
>> +
>> +It indicates the maximum number of the array free_area. This macro is
>> +used by the zone buddy allocator. User-space tools use this value to
>> +iterate the free_area.
>> +
>> +log_buf
>> +-------
>> +
>> +Console output is written to the ring buffer log_buf at index
>> +log_first_idx. Used to get the kernel log.
>> +
>> +log_buf_len
>> +-----------
>> +
>> +Length of a log_buf. Used to read the number of strings from the
>> +log_buf.
>> +
>> +log_first_idx
>> +-------------
>> +
>> +Index of the first record stored in the buffer log_buf. Used by
>> +user-space tools to read the strings in the log_buf.
>> +
>> +clear_idx
>> +---------
>> +
>> +The index that the next printk() record to read after the last clear
>> +command. It indicates the first record after the last SYSLOG_ACTION
>> +_CLEAR, like issued by 'dmesg -c'. Used by user-space tools to dump
>> +the dmesg log.
>> +
>> +log_next_idx
>> +------------
>> +
>> +The index of the next record to store in the buffer log_buf. Used to
>> +compute the index of the current string position.
>> +
>> +printk_log
>> +----------
>> +
>> +The size of a structure printk_log. Used to compute the size of
>> +messages, and extract dmesg log. It can output human readable text.
>> +Encapsulate header information for log_buf, such as timestamp, syslog
>> +level, etc.
>> +
>> +(printk_log, ts_nsec|len|text_len|dict_len)
>> +-------------------------------------------
>> +
>> +It represents field offsets in struct printk_log. User space tools can
>> +parse it and check whether the values of printk_log's members have been
>> +changed.
>> +
>> +(free_area.free_list, MIGRATE_TYPES)
>> +------------------------------------
>> +
>> +The number of migrate types for pages. The free_list is divided into
>> +the array, it needs to know the number of the array when makedumpfile
>> +computes the number of free pages.
>> +
>> +NR_FREE_PAGES
>> +-------------
>> +
>> +On linux-2.6.21 or later, the number of free_pages is in
>> +vm_stat[NR_FREE_PAGES]. Used to get the number of free pages.
>> +
>> +PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision
>> +|PG_head_mask|PAGE_BUDDY_MAPCOUNT_VALUE(~PG_buddy)
>> +|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_offline)
>> +-----------------------------------------------------------------
>> +
>> +Page attributes. These flags are used to filter various unnecessary
>> +pages.
>> +
>> +HUGETLB_PAGE_DTOR
>> +-----------------
>> +
>> +The HUGETLB_PAGE_DTOR flag denotes hugetlbfs pages. Makedumpfile
>> +excludes these pages.
>> +
>> +======
>> +x86_64
>> +======
>> +
>> +phys_base
>> +---------
>> +
>> +Used to convert the virtual address of an exported kernel symbol to its
>> +physical address.
>> +
>> +init_top_pgt
>> +------------
>> +
>> +Used to walk through the whole page table and convert virtual addresses
>> +to physical addresses. The init_top_pgt is somewhat similar to the
>> +swapper_pg_dir, but it is only used in x86_64.
>> +
>> +pgtable_l5_enabled
>> +------------------
>> +
>> +User-space tools need to know whether the crash kernel was in 5-level
>> +paging mode.
>> +
>> +node_data
>> +---------
>> +
>> +This is a struct pglist_data array and stores all numa nodes
>> +information. Makedumpfile gets the pglist_data structure from it.
>> +
>> +(node_data, MAX_NUMNODES)
>> +-------------------------
>> +
>> +The maximum number of the nodes in system.
>> +
>> +KERNELOFFSET
>> +------------
>> +
>> +The kernel randomization offset. Used to compute the page offset. If
>> +KASLR is disabled, this value is zero.
>> +
>> +KERNEL_IMAGE_SIZE
>> +-----------------
>> +
>> +Currently unused by Makedumpfile. Used to compute the module virtual
>> +address by Crash.
>> +
>> +sme_mask
>> +--------
>> +
>> +For AMD machine with SME feature, it indicates the secure memory
>> +encryption mask. Makedumpfile tools need to know whether the crash
>> +kernel was encrypted. If SME is enabled in the first kernel, the crash
>> +kernel's page table (pgd/pud/pmd/pte) contains the memory encryption
>> +mask and this is used to remove the SME mask to obtain the true physical
>> +address.
>> +
>> +Currently, the sme_mask stores the value of sme_me_mask(bit 47). If need,
>> +the bit(sme_mask) might be redefined in the future, but the bit 63 will
>> +be reserved.
>> +
>> +For example:
>> +[ misc ][ enc bit ][ other misc SME info ]
>> +0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_..._0000
>> +63 59 55 51 47 43 39 35 31 27 ... 3
>> +
>> +======
>> +x86_32
>> +======
>> +
>> +X86_PAE
>> +-------
>> +
>> +Denotes whether physical address extensions are enabled. It has the cost
>> +of more page table lookup overhead, and also consumes more page table
>> +space per process. Used to check whether PAE was enabled in the crash
>> +kernel when converting virtual addresses to physical addresses.
>> +
>> +====
>> +ia64
>> +====
>> +
>> +pgdat_list|(pgdat_list, MAX_NUMNODES)
>> +-------------------------------------
>> +
>> +pg_data_t array storing all numa nodes information. MAX_NUMNODES
>> +indicates the number of the nodes.
>> +
>> +node_memblk|(node_memblk, NR_NODE_MEMBLKS)
>> +------------------------------------------
>> +
>> +List of node memory chunks. Filled when parsing SRAT table to obtain
>> +information about memory nodes. NR_NODE_MEMBLKS indicates the number
>> +of node memory chunks.
>> +
>> +These values are used to compute the number of nodes in the crash kernel.
>> +
>> +node_memblk_s|(node_memblk_s, start_paddr)|(node_memblk_s, size)
>> +----------------------------------------------------------------
>> +
>> +The size of a struct node_memblk_s and the offsets of the
>> +node_memblk_s's members. Used to compute the number of nodes.
>> +
>> +PGTABLE_3|PGTABLE_4
>> +-------------------
>> +
>> +User-space tools need to know whether the crash kernel was in 3-level or
>> +4-level paging mode. Used to distinguish the page table.
>> +
>> +=====
>> +ARM64
>> +=====
>> +
>> +VA_BITS
>> +-------
>> +
>> +The maximum number of bits for virtual addresses. Used to compute the
>> +virtual memory ranges.
>> +
>> +kimage_voffset
>> +--------------
>> +
>> +The offset between the kernel virtual and physical mappings. Used to
>> +translate virtual to physical addresses.
>> +
>> +PHYS_OFFSET
>> +-----------
>> +
>> +Indicates the physical address of the start of memory. Similar to
>> +kimage_voffset, which is used to translate virtual address to physical
>> +address.
>> +
>> +KERNELOFFSET
>> +------------
>> +
>> +The kernel randomization offset. Used to compute the page offset. If
>> +KASLR is disabled, this value is zero.
>> +
>> +====
>> +arm
>> +====
>> +
>> +ARM_LPAE
>> +--------
>> +
>> +It indicates whether the crash kernel supports large physical address
>> +extensions. Used to translate virtual address to physical address.
>> +
>> +====
>> +s390
>> +====
>> +
>> +lowcore_ptr
>> +----------
>> +
>> +An array with a pointer to the lowcore of every CPU. Used to print the
>> +psw and all registers information.
>> +
>> +high_memory
>> +-----------
>> +
>> +Used to get the vmalloc_start address from the high_memory symbol.
>> +
>> +(lowcore_ptr, NR_CPUS)
>> +----------------------
>> +
>> +The maximum number of CPUs.
>> +
>> +=======
>> +powerpc
>> +=======
>> +
>> +
>> +node_data|(node_data, MAX_NUMNODES)
>> +-----------------------------------
>> +
>> +See above.
>> +
>> +contig_page_data
>> +----------------
>> +
>> +See above.
>> +
>> +vmemmap_list
>> +------------
>> +
>> +The vmemmap_list maintains the entire vmemmap physical mapping. It can
>> +get vmemmap list count and populate vmemmap regions info. If the vmemmap
>> +address translation information is stored in the crash kernel, it helps
>> +to translate vmemmap kernel virtual addresses.
>> +
>> +mmu_vmemmap_psize
>> +-----------------
>> +
>> +The size of a page. Used to translate address to physical addresses.
>> +
>> +mmu_psize_defs
>> +--------------
>> +
>> +Page size definitions, i.e. 4k, 64k, or 16M.
>> +
>> +Used to make vtop translations.
>> +
>> +vmemmap_backing|(vmemmap_backing, list)|(vmemmap_backing, phys)|
>> +(vmemmap_backing, virt_addr)
>> +----------------------------------------------------------------
>> +
>> +The vmemmap virtual address space management does not have a traditional
>> +page table to track which virtual struct pages are backed by physical
>> +mapping. The virtual to physical mappings are tracked in a simple linked
>> +list format.
>> +
>> +User-space tools need to know the offset of list, phys and virt_addr
>> +when computing the count of vmemmap regions.
>> +
>> +mmu_psize_def|(mmu_psize_def, shift)
>> +------------------------------------
>> +
>> +The size of a struct mmu_psize_def and the offset of mmu_psize_def's
>> +member.
>> +
>> +Used in vtop translations.
>> +
>> +==
>> +sh
>> +==
>> +
>> +node_data|(node_data, MAX_NUMNODES)
>> +-----------------------------------
>> +
>> +See above.
>> +
>> +X2TLB
>> +-----
>> +
>> +Indicates whether the crash kernel enables SH extended mode.
>> --
>> 2.17.1
>>
>
>
在 2019年01月07日 10:29, Baoquan He 写道:
> On 01/07/19 at 09:47am, Lianbo Jiang wrote:
>> For AMD machine with SME feature, makedumpfile tools need to know
>> whether the crash kernel was encrypted or not. If SME is enabled
> ^ crashed
>> in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
> ^ crashed
>> contains the memory encryption mask, so need to remove the sme mask
> "makedumpfile needs" or
> in makedumpfile need to remove...
Thanks for your comment.
This will be modified in next post.
Regards,
Lianbo
>> to obtain the true physical address.
>>
>> Signed-off-by: Lianbo Jiang <[email protected]>
>> ---
>> arch/x86/kernel/machine_kexec_64.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
>> index 4c8acdfdc5a7..bc4108096b18 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -352,10 +352,13 @@ void machine_kexec(struct kimage *image)
>>
>> void arch_crash_save_vmcoreinfo(void)
>> {
>> + u64 sme_mask = sme_me_mask;
>> +
>> VMCOREINFO_NUMBER(phys_base);
>> VMCOREINFO_SYMBOL(init_top_pgt);
>> vmcoreinfo_append_str("NUMBER(pgtable_l5_enabled)=%d\n",
>> pgtable_l5_enabled());
>> + VMCOREINFO_NUMBER(sme_mask);
>>
>> #ifdef CONFIG_NUMA
>> VMCOREINFO_SYMBOL(node_data);
>> --
>> 2.17.1
>>