[Makedumpfile PATCH V2 1/4] x86_64: Calculate page_offset from pt

Currently we translate some of the VA areas using linear mapping while some
other(which can not be linearly mapped) using page table.

However, we will have entry of a page in the page table irrespective of its
virtual region. So, we can always look into page table for any VA to PA
translation. This approach will solve lot of complexity in makedumpfile. It
will in turn remove dependency over variables like VMALLOC_START,
MODULES_VADDR etc whose definition keeps changing in newer kernel version.

Moreover, I do not see any side effect of this approach in terms of
execution timing. I tested with IBM x3950 X6 machine having 4136359 MB of
memory with -d 1 option. In fact, over a 19+ trials, new code shows
slightly better result (2592 S) than upstream code (2652 S). These are the
results of makedumpfile execution time:

$ cat console.log | grep "makedumpfile execution time with upstream code
is"
makedumpfile execution time with upstream code is 2750.243266765
makedumpfile execution time with upstream code is 2772.954322748
makedumpfile execution time with upstream code is 2778.147847869
makedumpfile execution time with upstream code is 2668.136180424
makedumpfile execution time with upstream code is 2543.101660682
makedumpfile execution time with upstream code is 2757.314292073
makedumpfile execution time with upstream code is 2478.658846427
makedumpfile execution time with upstream code is 2745.728099825
makedumpfile execution time with upstream code is 2577.807602709
makedumpfile execution time with upstream code is 2548.787385748
makedumpfile execution time with upstream code is 2757.644602365
makedumpfile execution time with upstream code is 2562.336482019
makedumpfile execution time with upstream code is 2559.935682252
makedumpfile execution time with upstream code is 2546.670738446
makedumpfile execution time with upstream code is 2744.063245015
makedumpfile execution time with upstream code is 2744.243866098
makedumpfile execution time with upstream code is 2549.050846459
makedumpfile execution time with upstream code is 2759.081822434
makedumpfile execution time with upstream code is 2549.571317987
$ cat console.log | grep "makedumpfile execution time with upstream code
is" | cut -d ' ' -f 8 | awk -F : '{sum+=$1} END {print "AVG=",sum/NR}'
AVG= 2652.29

$ cat console.log | grep "makedumpfile execution time with new code is"
makedumpfile execution time with new code is 2534.312841588
makedumpfile execution time with new code is 2549.943691468
makedumpfile execution time with new code is 2562.056355355
makedumpfile execution time with new code is 2744.429671429
makedumpfile execution time with new code is 2536.959188162
makedumpfile execution time with new code is 2543.148060626
makedumpfile execution time with new code is 2548.634229064
makedumpfile execution time with new code is 2554.985669453
makedumpfile execution time with new code is 2756.479546003
makedumpfile execution time with new code is 2736.303174442
makedumpfile execution time with new code is 2564.855527093
makedumpfile execution time with new code is 2479.417937688
makedumpfile execution time with new code is 2555.431578921
makedumpfile execution time with new code is 2741.293207275
makedumpfile execution time with new code is 2745.547802440
makedumpfile execution time with new code is 2555.950078489
makedumpfile execution time with new code is 2558.421768940
makedumpfile execution time with new code is 2534.342072864
makedumpfile execution time with new code is 2542.824611652
makedumpfile execution time with new code is 2557.413054122
makedumpfile execution time with new code is 2553.609188082
makedumpfile execution time with new code is 2766.161683444
makedumpfile execution time with new code is 2571.997408197
makedumpfile execution time with new code is 2541.121903364
makedumpfile execution time with new code is 2472.805795262
$ cat console.log | grep "makedumpfile execution time with new code is" |
cut -d ' ' -f 8 | awk -F : '{sum+=$1} END {print "AVG=",sum/NR}'
AVG= 2592.34

Signed-off-by: Pratyush Anand <***@redhat.com>
---
arch/x86_64.c | 42 ++++++++----------------------------------
makedumpfile.h | 4 ++--
2 files changed, 10 insertions(+), 36 deletions(-)

diff --git a/arch/x86_64.c b/arch/x86_64.c
index eba725e41aac..9afa38fd141a 100644
--- a/arch/x86_64.c
+++ b/arch/x86_64.c
@@ -203,6 +203,12 @@ vtop4_x86_64(unsigned long vaddr)
{
unsigned long page_dir, pml4, pgd_paddr, pgd_pte, pmd_paddr, pmd_pte;
unsigned long pte_paddr, pte;
+ unsigned long phys_base;
+
+ if (SYMBOL(phys_base) != NOT_FOUND_SYMBOL)
+ phys_base = info->phys_base;
+ else
+ phys_base = 0;

if (SYMBOL(init_level4_pgt) == NOT_FOUND_SYMBOL) {
ERRMSG("Can't get the symbol of init_level4_pgt.\n");
@@ -212,9 +218,9 @@ vtop4_x86_64(unsigned long vaddr)
/*
* Get PGD.
*/
- page_dir = SYMBOL(init_level4_pgt);
+ page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;
page_dir += pml4_index(vaddr) * sizeof(unsigned long);
- if (!readmem(VADDR, page_dir, &pml4, sizeof pml4)) {
+ if (!readmem(PADDR, page_dir, &pml4, sizeof pml4)) {
ERRMSG("Can't get pml4 (page_dir:%lx).\n", page_dir);
return NOT_PADDR;
}
@@ -285,38 +291,6 @@ vtop4_x86_64(unsigned long vaddr)
return (pte & ENTRY_MASK) + PAGEOFFSET(vaddr);
}

-unsigned long long
-vaddr_to_paddr_x86_64(unsigned long vaddr)
-{
- unsigned long phys_base;
- unsigned long long paddr;
-
- /*
- * Check the relocatable kernel.
- */
- if (SYMBOL(phys_base) != NOT_FOUND_SYMBOL)
- phys_base = info->phys_base;
- else
- phys_base = 0;
-
- if (is_vmalloc_addr_x86_64(vaddr)) {
- if ((paddr = vtop4_x86_64(vaddr)) == NOT_PADDR) {
- ERRMSG("Can't convert a virtual address(%lx) to " \
- "physical address.\n", vaddr);
- return NOT_PADDR;
- }
- } else if (vaddr >= __START_KERNEL_map) {
- paddr = vaddr - __START_KERNEL_map + phys_base;
-
- } else {
- if (is_xen_memory())
- paddr = vaddr - PAGE_OFFSET_XEN_DOM0;
- else
- paddr = vaddr - PAGE_OFFSET;
- }
- return paddr;
-}
-
/*
* for Xen extraction
*/
diff --git a/makedumpfile.h b/makedumpfile.h
index a5955ff750e5..13559651feb6 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -863,12 +863,12 @@ int is_vmalloc_addr_x86_64(ulong vaddr);
int get_phys_base_x86_64(void);
int get_machdep_info_x86_64(void);
int get_versiondep_info_x86_64(void);
-unsigned long long vaddr_to_paddr_x86_64(unsigned long vaddr);
+unsigned long long vtop4_x86_64(unsigned long vaddr);
#define find_vmemmap() find_vmemmap_x86_64()
#define get_phys_base() get_phys_base_x86_64()
#define get_machdep_info() get_machdep_info_x86_64()
#define get_versiondep_info() get_versiondep_info_x86_64()
-#define vaddr_to_paddr(X) vaddr_to_paddr_x86_64(X)
+#define vaddr_to_paddr(X) vtop4_x86_64(X)
#define is_phys_addr(X) (!is_vmalloc_addr_x86_64(X))
#endif /* x86_64 */

--
2.7.4

Atsushi Kumagai

2016-12-09 07:35:55 UTC

Hello Pratyush,

Post by Pratyush Anand
---
arch/x86_64.c | 42 ++++++++----------------------------------
makedumpfile.h | 4 ++--
2 files changed, 10 insertions(+), 36 deletions(-)
diff --git a/arch/x86_64.c b/arch/x86_64.c
index eba725e41aac..9afa38fd141a 100644
--- a/arch/x86_64.c
+++ b/arch/x86_64.c
@@ -203,6 +203,12 @@ vtop4_x86_64(unsigned long vaddr)
{
unsigned long page_dir, pml4, pgd_paddr, pgd_pte, pmd_paddr, pmd_pte;
unsigned long pte_paddr, pte;
+ unsigned long phys_base;
+
+ if (SYMBOL(phys_base) != NOT_FOUND_SYMBOL)
+ phys_base = info->phys_base;
+ else
+ phys_base = 0;
if (SYMBOL(init_level4_pgt) == NOT_FOUND_SYMBOL) {
ERRMSG("Can't get the symbol of init_level4_pgt.\n");
@@ -212,9 +218,9 @@ vtop4_x86_64(unsigned long vaddr)
/*
* Get PGD.
*/
- page_dir = SYMBOL(init_level4_pgt);
+ page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;

I found that this change breaks the backward compatibility for
kernel 2.6.21 or older since phys_base was introduced in kernel 2.6.22
by the commit below:

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Author: Vivek Goyal <***@in.ibm.com>
Date: Wed May 2 19:27:07 2007 +0200

[PATCH] x86-64: Relocatable Kernel Support

There is no problem if phys_base is always 0 in older kernel, but
get_phys_base_x86_64() calculates "phys_base = 0x100000" from my vmcore:

Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
0x0000000000000590 0x0000000000000590 0
LOAD 0x0000000000000720 0xffffffff80000000 0x0000000000100000 // CONFIG_PHYSICAL_START = 0x100000
0x00000000008b2000 0x00000000008b2000 RWE 0
LOAD 0x00000000008b2720 0xffff810000000000 0x0000000000000000
0x00000000000a0000 0x00000000000a0000 RWE 0
LOAD 0x0000000000952720 0xffff810000100000 0x0000000000100000
0x0000000000f00000 0x0000000000f00000 RWE 0
LOAD 0x0000000001852720 0xffff810005000000 0x0000000005000000
0x00000000caf70000 0x00000000caf70000 RWE 0
LOAD 0x00000000cc7c2720 0xffff810100000000 0x0000000100000000
0x0000000070000000 0x0000000070000000 RWE 0

Of course we shouldn't use that invalid phys_base:

crash> sym init_level4_pgt
ffffffff80101000 (T) init_level4_pgt
crash> vtop ffffffff80101000
VIRTUAL PHYSICAL
ffffffff80101000 101000 // just "VIRTUAL - __START_KERNEL_map"

PML4 DIRECTORY: ffffffff80101000
PAGE DIRECTORY: 103027
PUD: 103ff0 => 105027
PMD: 105000 => 1e3
PAGE: 0 (2MB)

PTE PHYSICAL FLAGS
1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810005004838 101000 0 0 1 400
crash>

At first I thought about setting 0 to phys_base if the kernel is
older than 2.6.22, but unfortunately we can't get the kernel version
before getting correct phys_base since VtoP is necessary to read
system_utsname.
(and 2.6.21 doesn't have VMCOREINFO, OSRELEASE can't be used too.)

Do you have any ideas for this issue ?

Thanks,
Atsushi Kumagai

Post by Pratyush Anand
page_dir += pml4_index(vaddr) * sizeof(unsigned long);
- if (!readmem(VADDR, page_dir, &pml4, sizeof pml4)) {
+ if (!readmem(PADDR, page_dir, &pml4, sizeof pml4)) {
ERRMSG("Can't get pml4 (page_dir:%lx).\n", page_dir);
return NOT_PADDR;
}
@@ -285,38 +291,6 @@ vtop4_x86_64(unsigned long vaddr)
return (pte & ENTRY_MASK) + PAGEOFFSET(vaddr);
}
-unsigned long long
-vaddr_to_paddr_x86_64(unsigned long vaddr)
-{
- unsigned long phys_base;
- unsigned long long paddr;
-
- /*
- * Check the relocatable kernel.
- */
- if (SYMBOL(phys_base) != NOT_FOUND_SYMBOL)
- phys_base = info->phys_base;
- else
- phys_base = 0;
-
- if (is_vmalloc_addr_x86_64(vaddr)) {
- if ((paddr = vtop4_x86_64(vaddr)) == NOT_PADDR) {
- ERRMSG("Can't convert a virtual address(%lx) to " \
- "physical address.\n", vaddr);
- return NOT_PADDR;
- }
- } else if (vaddr >= __START_KERNEL_map) {
- paddr = vaddr - __START_KERNEL_map + phys_base;
-
- } else {
- if (is_xen_memory())
- paddr = vaddr - PAGE_OFFSET_XEN_DOM0;
- else
- paddr = vaddr - PAGE_OFFSET;
- }
- return paddr;
-}
-
/*
* for Xen extraction
*/
diff --git a/makedumpfile.h b/makedumpfile.h
index a5955ff750e5..13559651feb6 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -863,12 +863,12 @@ int is_vmalloc_addr_x86_64(ulong vaddr);
int get_phys_base_x86_64(void);
int get_machdep_info_x86_64(void);
int get_versiondep_info_x86_64(void);
-unsigned long long vaddr_to_paddr_x86_64(unsigned long vaddr);
+unsigned long long vtop4_x86_64(unsigned long vaddr);
#define find_vmemmap() find_vmemmap_x86_64()
#define get_phys_base() get_phys_base_x86_64()
#define get_machdep_info() get_machdep_info_x86_64()
#define get_versiondep_info() get_versiondep_info_x86_64()
-#define vaddr_to_paddr(X) vaddr_to_paddr_x86_64(X)
+#define vaddr_to_paddr(X) vtop4_x86_64(X)
#define is_phys_addr(X) (!is_vmalloc_addr_x86_64(X))
#endif /* x86_64 */
--
2.7.4
_______________________________________________
kexec mailing list
http://lists.infradead.org/mailman/listinfo/kexec

Pratyush Anand

2016-12-09 10:10:21 UTC

Post by Atsushi Kumagai
Hello Pratyush,

I found that this change breaks the backward compatibility for
kernel 2.6.21 or older since phys_base was introduced in kernel 2.6.22
commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Date: Wed May 2 19:27:07 2007 +0200
[PATCH] x86-64: Relocatable Kernel Support
There is no problem if phys_base is always 0 in older kernel, but
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
0x0000000000000590 0x0000000000000590 0
LOAD 0x0000000000000720 0xffffffff80000000 0x0000000000100000 // CONFIG_PHYSICAL_START = 0x100000
0x00000000008b2000 0x00000000008b2000 RWE 0
LOAD 0x00000000008b2720 0xffff810000000000 0x0000000000000000
0x00000000000a0000 0x00000000000a0000 RWE 0
LOAD 0x0000000000952720 0xffff810000100000 0x0000000000100000
0x0000000000f00000 0x0000000000f00000 RWE 0
LOAD 0x0000000001852720 0xffff810005000000 0x0000000005000000
0x00000000caf70000 0x00000000caf70000 RWE 0
LOAD 0x00000000cc7c2720 0xffff810100000000 0x0000000100000000
0x0000000070000000 0x0000000070000000 RWE 0
crash> sym init_level4_pgt
ffffffff80101000 (T) init_level4_pgt
crash> vtop ffffffff80101000
VIRTUAL PHYSICAL
ffffffff80101000 101000 // just "VIRTUAL - __START_KERNEL_map"
PML4 DIRECTORY: ffffffff80101000
PAGE DIRECTORY: 103027
PUD: 103ff0 => 105027
PMD: 105000 => 1e3
PAGE: 0 (2MB)
PTE PHYSICAL FLAGS
1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810005004838 101000 0 0 1 400
crash>
At first I thought about setting 0 to phys_base if the kernel is
older than 2.6.22, but unfortunately we can't get the kernel version
before getting correct phys_base since VtoP is necessary to read
system_utsname.
(and 2.6.21 doesn't have VMCOREINFO, OSRELEASE can't be used too.)

We can use this fact may be. So, when has_vmcoreinfo() is false we can
consider it as old kernel and can set phys_start as 0.

Bao, any opnion?

~Pratyush

b***@redhat.com

2016-12-09 14:25:15 UTC

Post by Pratyush Anand
- page_dir = SYMBOL(init_level4_pgt);
+ page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;

This is really awkward. Checked code, found PAGE_OFFSET is
0xffff810000000000 before 2.6.26, then changed to 0xffff880000000000
after that. Can we check the page_offset calculated from pt_load
segments, meanwhile check if has VMCOREINFO and osrelease after 2.6.21.

With both of above condition, we could set phys_vase to 0. Not sure if
this can solve the existing problem.

Post by Atsushi Kumagai
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
0x0000000000000590 0x0000000000000590 0
LOAD 0x0000000000000720 0xffffffff80000000 0x0000000000100000 // CONFIG_PHYSICAL_START = 0x100000
0x00000000008b2000 0x00000000008b2000 RWE 0
LOAD 0x00000000008b2720 0xffff810000000000 0x0000000000000000
0x00000000000a0000 0x00000000000a0000 RWE 0
LOAD 0x0000000000952720 0xffff810000100000 0x0000000000100000
0x0000000000f00000 0x0000000000f00000 RWE 0
LOAD 0x0000000001852720 0xffff810005000000 0x0000000005000000
0x00000000caf70000 0x00000000caf70000 RWE 0
LOAD 0x00000000cc7c2720 0xffff810100000000 0x0000000100000000
0x0000000070000000 0x0000000070000000 RWE 0
crash> sym init_level4_pgt
ffffffff80101000 (T) init_level4_pgt
crash> vtop ffffffff80101000
VIRTUAL PHYSICAL
ffffffff80101000 101000 // just "VIRTUAL - __START_KERNEL_map"
PML4 DIRECTORY: ffffffff80101000
PAGE DIRECTORY: 103027
PUD: 103ff0 => 105027
PMD: 105000 => 1e3
PAGE: 0 (2MB)
PTE PHYSICAL FLAGS
1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810005004838 101000 0 0 1 400
crash>
At first I thought about setting 0 to phys_base if the kernel is
older than 2.6.22, but unfortunately we can't get the kernel version
before getting correct phys_base since VtoP is necessary to read
system_utsname.
(and 2.6.21 doesn't have VMCOREINFO, OSRELEASE can't be used too.)

We can use this fact may be. So, when has_vmcoreinfo() is false we can
consider it as old kernel and can set phys_start as 0.
Bao, any opnion?
~Pratyush

b***@redhat.com

2016-12-10 01:29:15 UTC

Post by Pratyush Anand
- page_dir = SYMBOL(init_level4_pgt);
+ page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;

This is really awkward. Checked code, found PAGE_OFFSET is
0xffff810000000000 before 2.6.26, then changed to 0xffff880000000000
after that. Can we check the page_offset calculated from pt_load
segments, meanwhile check if has VMCOREINFO and osrelease after 2.6.21.
With both of above condition, we could set phys_vase to 0. Not sure if
this can solve the existing problem.

I meant making a judgement:

if (page_offset == 0xffff810000000000 && info->kernel_version > KERNEL_VERSION(2, 6, 21))
info->phys_base = 0;

We can use this fact may be. So, when has_vmcoreinfo() is false we can
consider it as old kernel and can set phys_start as 0.
Bao, any opnion?
~Pratyush

b***@redhat.com

2016-12-10 01:33:30 UTC

Post by Pratyush Anand
- page_dir = SYMBOL(init_level4_pgt);
+ page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;

This is really awkward. Checked code, found PAGE_OFFSET is
0xffff810000000000 before 2.6.26, then changed to 0xffff880000000000
after that. Can we check the page_offset calculated from pt_load
segments, meanwhile check if has VMCOREINFO and osrelease after 2.6.21.
With both of above condition, we could set phys_vase to 0. Not sure if
this can solve the existing problem.

Sorry, should be:
if (page_offset == 0xffff810000000000 && !info->kernel_version > KERNEL_VERSION(2, 6, 21))
info->phys_base = 0;

We can use this fact may be. So, when has_vmcoreinfo() is false we can
consider it as old kernel and can set phys_start as 0.
Bao, any opnion?
~Pratyush

Pratyush Anand

2016-12-10 06:20:17 UTC

Post by Pratyush Anand
- page_dir = SYMBOL(init_level4_pgt);
+ page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;

This is really awkward. Checked code, found PAGE_OFFSET is
0xffff810000000000 before 2.6.26, then changed to 0xffff880000000000
after that. Can we check the page_offset calculated from pt_load
segments, meanwhile check if has VMCOREINFO and osrelease after 2.6.21.
With both of above condition, we could set phys_vase to 0. Not sure if
this can solve the existing problem.

if (page_offset == 0xffff810000000000 && !info->kernel_version > KERNEL_VERSION(2, 6, 21))
info->phys_base = 0;

But you can not read kernel_version because those version does not have
VMCOREINFO. So, has_vmcoreinfo() still need to be used.

~Pratyush

We can use this fact may be. So, when has_vmcoreinfo() is false we can
consider it as old kernel and can set phys_start as 0.
Bao, any opnion?
~Pratyush

Atsushi Kumagai

2016-12-12 08:40:56 UTC

Post by Pratyush Anand
- page_dir = SYMBOL(init_level4_pgt);
+ page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;

This is really awkward. Checked code, found PAGE_OFFSET is
0xffff810000000000 before 2.6.26, then changed to 0xffff880000000000
after that. Can we check the page_offset calculated from pt_load
segments, meanwhile check if has VMCOREINFO and osrelease after 2.6.21.
With both of above condition, we could set phys_vase to 0. Not sure if
this can solve the existing problem.

if (page_offset == 0xffff810000000000 && !info->kernel_version > KERNEL_VERSION(2, 6, 21))
info->phys_base = 0;

But you can not read kernel_version because those version does not have
VMCOREINFO. So, has_vmcoreinfo() still need to be used.

Thanks for your comments, using has_vmcoreinfo() sounds like a good approach,
but not perfect way. VMCOREINFO has been introduced since 2.6.24,
2.6.22 and 2.6.23 don't have VMCOREINFO but have phys_base.

Conversely, 2.6.22 and 2.6.23 require vmlinux, so we can confirm the existence of
phys_base with that. My idea is:

diff --git a/arch/x86_64.c b/arch/x86_64.c
index 010ea10..893cd51 100644
--- a/arch/x86_64.c
+++ b/arch/x86_64.c
@@ -67,6 +67,14 @@ get_phys_base_x86_64(void)
return TRUE;
}

+ /* linux-2.6.21 or older don't have phys_base, should be set to 0. */
+ if (!has_vmcoreinfo()) {
+ SYMBOL_INIT(phys_base, "phys_base");
+ if (SYMBOL(phys_base) == NOT_FOUND_SYMBOL) {
+ return TRUE;
+ }
+ }
+
for (i = 0; get_pt_load(i, &phys_start, NULL, &virt_start, NULL); i++) {
if (virt_start >= __START_KERNEL_map) {

This fix may resolve my issue, but now I have another question that
"Is the logic of get_phys_base_x86_64() correct in any kernel configuration ?"
I mean I'm worried about the possibility that another offset gets mixed with
the result of get_phys_base_x86_64() like my 2.6.21 case.
After phys_base was introduced, does it always equal to the offset which can be
calculated from PT_LOAD headers ?

Thanks,
Atsushi Kumagai

Post by Pratyush Anand
~Pratyush

We can use this fact may be. So, when has_vmcoreinfo() is false we can
consider it as old kernel and can set phys_start as 0.
Bao, any opnion?
~Pratyush

_______________________________________________
kexec mailing list
http://lists.infradead.org/mailman/listinfo/kexec

b***@redhat.com

2016-12-12 09:50:20 UTC

Post by Pratyush Anand
- page_dir = SYMBOL(init_level4_pgt);
+ page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;

This is really awkward. Checked code, found PAGE_OFFSET is
0xffff810000000000 before 2.6.26, then changed to 0xffff880000000000
after that. Can we check the page_offset calculated from pt_load
segments, meanwhile check if has VMCOREINFO and osrelease after 2.6.21.
With both of above condition, we could set phys_vase to 0. Not sure if
this can solve the existing problem.

if (page_offset == 0xffff810000000000 && !info->kernel_version > KERNEL_VERSION(2, 6, 21))
info->phys_base = 0;

But you can not read kernel_version because those version does not have
VMCOREINFO. So, has_vmcoreinfo() still need to be used.

Thanks for your comments, using has_vmcoreinfo() sounds like a good approach,
but not perfect way. VMCOREINFO has been introduced since 2.6.24,
2.6.22 and 2.6.23 don't have VMCOREINFO but have phys_base.
Conversely, 2.6.22 and 2.6.23 require vmlinux, so we can confirm the existence of
diff --git a/arch/x86_64.c b/arch/x86_64.c
index 010ea10..893cd51 100644
--- a/arch/x86_64.c
+++ b/arch/x86_64.c
@@ -67,6 +67,14 @@ get_phys_base_x86_64(void)
return TRUE;
}
+ /* linux-2.6.21 or older don't have phys_base, should be set to 0. */
+ if (!has_vmcoreinfo()) {
+ SYMBOL_INIT(phys_base, "phys_base");
+ if (SYMBOL(phys_base) == NOT_FOUND_SYMBOL) {
+ return TRUE;
+ }
+ }
+
for (i = 0; get_pt_load(i, &phys_start, NULL, &virt_start, NULL); i++) {
if (virt_start >= __START_KERNEL_map) {
This fix may resolve my issue, but now I have another question that
"Is the logic of get_phys_base_x86_64() correct in any kernel configuration ?"
I mean I'm worried about the possibility that another offset gets mixed with
the result of get_phys_base_x86_64() like my 2.6.21 case.
After phys_base was introduced, does it always equal to the offset which can be
calculated from PT_LOAD headers ?

Don't worry. phys_base was introduced just after 2.6.21.

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Author: Vivek Goyal <***@in.ibm.com>
Date: Wed May 2 19:27:07 2007 +0200

[PATCH] x86-64: Relocatable Kernel Support

[***@x1 linux]$ git describe 1ab60e0f72f71ec54831e525a3e1154f1c092408
v2.6.21-1836-g1ab60e0

Thanks
Baoquan

Atsushi Kumagai

2016-12-13 07:03:12 UTC

Post by Pratyush Anand
- page_dir = SYMBOL(init_level4_pgt);
+ page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;

This is really awkward. Checked code, found PAGE_OFFSET is
0xffff810000000000 before 2.6.26, then changed to 0xffff880000000000
after that. Can we check the page_offset calculated from pt_load
segments, meanwhile check if has VMCOREINFO and osrelease after 2.6.21.
With both of above condition, we could set phys_vase to 0. Not sure if
this can solve the existing problem.

if (page_offset == 0xffff810000000000 && !info->kernel_version > KERNEL_VERSION(2, 6, 21))
info->phys_base = 0;

But you can not read kernel_version because those version does not have
VMCOREINFO. So, has_vmcoreinfo() still need to be used.

Thanks for your comments, using has_vmcoreinfo() sounds like a good approach,
but not perfect way. VMCOREINFO has been introduced since 2.6.24,
2.6.22 and 2.6.23 don't have VMCOREINFO but have phys_base.
Conversely, 2.6.22 and 2.6.23 require vmlinux, so we can confirm the existence of
diff --git a/arch/x86_64.c b/arch/x86_64.c
index 010ea10..893cd51 100644
--- a/arch/x86_64.c
+++ b/arch/x86_64.c
@@ -67,6 +67,14 @@ get_phys_base_x86_64(void)
return TRUE;
}
+ /* linux-2.6.21 or older don't have phys_base, should be set to 0. */
+ if (!has_vmcoreinfo()) {
+ SYMBOL_INIT(phys_base, "phys_base");
+ if (SYMBOL(phys_base) == NOT_FOUND_SYMBOL) {
+ return TRUE;
+ }
+ }
+
for (i = 0; get_pt_load(i, &phys_start, NULL, &virt_start, NULL); i++) {
if (virt_start >= __START_KERNEL_map) {
This fix may resolve my issue, but now I have another question that
"Is the logic of get_phys_base_x86_64() correct in any kernel configuration ?"
I mean I'm worried about the possibility that another offset gets mixed with
the result of get_phys_base_x86_64() like my 2.6.21 case.
After phys_base was introduced, does it always equal to the offset which can be
calculated from PT_LOAD headers ?

Don't worry. phys_base was introduced just after 2.6.21.
commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Date: Wed May 2 19:27:07 2007 +0200
[PATCH] x86-64: Relocatable Kernel Support
v2.6.21-1836-g1ab60e0

All right, thanks.
I'll release v1.6.1 soon if there is nothing wrong with the retest.

Regards,
Atsushi Kumagai

Pratyush Anand

2016-10-31 08:17:36 UTC

From kernel documentation:
ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0
ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space

So, it is only the module area which is lying above __START_KERNEL_map.
However, kexec-tools only creates PT_LOAD segments for kernel text region
and crash memory region. So, we can safely remove the check for
!is_vmalloc_addr_x86_64() from get_phys_base_x86_64().

Since, this was the last usage of is_vmalloc_addr_x86_64(), so kill it as
well.

Signed-off-by: Pratyush Anand <***@redhat.com>
---
arch/x86_64.c | 14 +-------------
makedumpfile.h | 3 +--
2 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/x86_64.c b/arch/x86_64.c
index 9afa38fd141a..9e2940ca75d9 100644
--- a/arch/x86_64.c
+++ b/arch/x86_64.c
@@ -21,17 +21,6 @@
extern struct vmap_pfns *gvmem_pfns;
extern int nr_gvmem_pfns;

-int
-is_vmalloc_addr_x86_64(ulong vaddr)
-{
- /*
- * vmalloc, virtual memmap, and module space as VMALLOC space.
- */
- return ((vaddr >= VMALLOC_START && vaddr <= VMALLOC_END)
- || (vaddr >= VMEMMAP_START && vaddr <= VMEMMAP_END)
- || (vaddr >= MODULES_VADDR && vaddr <= MODULES_END));
-}
-
static unsigned long
get_xen_p2m_mfn(void)
{
@@ -75,8 +64,7 @@ get_phys_base_x86_64(void)
info->phys_base = 0; /* default/traditional */

for (i = 0; get_pt_load(i, &phys_start, NULL, &virt_start, NULL); i++) {
- if ((virt_start >= __START_KERNEL_map) &&
- !(is_vmalloc_addr_x86_64(virt_start))) {
+ if (virt_start >= __START_KERNEL_map) {

info->phys_base = phys_start -
(virt_start & ~(__START_KERNEL_map));
diff --git a/makedumpfile.h b/makedumpfile.h
index 13559651feb6..8a96da1f61bd 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -859,7 +859,6 @@ unsigned long long vaddr_to_paddr_x86(unsigned long vaddr);
#endif /* x86 */

#ifdef __x86_64__
-int is_vmalloc_addr_x86_64(ulong vaddr);
int get_phys_base_x86_64(void);
int get_machdep_info_x86_64(void);
int get_versiondep_info_x86_64(void);
@@ -869,7 +868,7 @@ unsigned long long vtop4_x86_64(unsigned long vaddr);
#define get_machdep_info() get_machdep_info_x86_64()
#define get_versiondep_info() get_versiondep_info_x86_64()
#define vaddr_to_paddr(X) vtop4_x86_64(X)
-#define is_phys_addr(X) (!is_vmalloc_addr_x86_64(X))
+#define is_phys_addr(X) stub_true_ul(X)
#endif /* x86_64 */

#ifdef __powerpc64__ /* powerpc64 */

--
2.7.4

Pratyush Anand

2016-10-31 08:17:37 UTC

VMALLOC_START, VMALLOC_END, MODULES_VADDR and MODULES_END are mo more
needed for x86_64 now. So, kill their initialization.

Signed-off-by: Pratyush Anand <***@redhat.com>
---
arch/x86_64.c | 4 ----
makedumpfile.h | 2 --
2 files changed, 6 deletions(-)

diff --git a/arch/x86_64.c b/arch/x86_64.c
index 9e2940ca75d9..3ef33ae4ef2d 100644
--- a/arch/x86_64.c
+++ b/arch/x86_64.c
@@ -169,13 +169,9 @@ get_versiondep_info_x86_64(void)
return FALSE;

if (info->kernel_version < KERNEL_VERSION(2, 6, 31)) {
- info->vmalloc_start = VMALLOC_START_ORIG;
- info->vmalloc_end = VMALLOC_END_ORIG;
info->vmemmap_start = VMEMMAP_START_ORIG;
info->vmemmap_end = VMEMMAP_END_ORIG;
} else {
- info->vmalloc_start = VMALLOC_START_2_6_31;
- info->vmalloc_end = VMALLOC_END_2_6_31;
info->vmemmap_start = VMEMMAP_START_2_6_31;
info->vmemmap_end = VMEMMAP_END_2_6_31;
}
diff --git a/makedumpfile.h b/makedumpfile.h
index 8a96da1f61bd..338c651388f0 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -575,8 +575,6 @@ int get_va_bits_arm64(void);
#define __START_KERNEL_map (0xffffffff80000000)
#define KERNEL_IMAGE_SIZE_ORIG (0x0000000008000000) /* 2.6.25, or former */
#define KERNEL_IMAGE_SIZE_2_6_26 (0x0000000020000000) /* 2.6.26, or later */
-#define MODULES_VADDR (__START_KERNEL_map + NUMBER(KERNEL_IMAGE_SIZE))
-#define MODULES_END (0xfffffffffff00000)
#define KVBASE PAGE_OFFSET
#define _SECTION_SIZE_BITS (27)
#define _MAX_PHYSMEM_BITS_ORIG (40)

--
2.7.4

Dave Young

2016-11-01 05:34:11 UTC

Pratyush, the patches works for me, thanks~

Patch 1/4 fixes page_offset calculation, so that it is correctly calculated
on KASLR enabled kernel as well.
Patch 2/4 simplifies VA to PA translation. New code has been benchmarked
against old code on a 4T system.
Patch 3/4 and 4/4 is removal of (now) unnecessary code.
I think, we should find a way to kill find_vememmap() as well, so that
VMEMMAP_START can be removed. I have very limited idea about x86, so unable
to do that as of now.

It was introduced in below commit, ccing Cliff Wickman, see if he has
thoughts.

commit 46176a97f329904c10d4efe5582594d55a04339c
Author: Cliff Wickman <***@sgi.com>
Date: Mon Oct 26 23:20:18 2015 +0900

* A bug in patch 1/4 fixed
* Patch log of 2/4 improved to include more number of trials
x86_64: Calculate page_offset from pt_load
x86_64: translate all VA to PA using page table values
x86_64: kill is_vmalloc_addr_x86_64()
x86_64: kill some unused initialization
arch/x86_64.c | 84 ++++++++++++++++++++--------------------------------------
makedumpfile.h | 9 +++----
2 files changed, 32 insertions(+), 61 deletions(-)
--
2.7.4
_______________________________________________
kexec mailing list
http://lists.infradead.org/mailman/listinfo/kexec

Atsushi Kumagai

2016-11-04 10:35:29 UTC