x86_64: Fix page_offset for randomized base enabled

---
arch/x86_64.c | 42 ++++++++---------------------------------- makedumpfile.h | 4 ++--

2 files changed, 10 insertions(+), 36 deletions(-)

arch/x86_64.c +6 -0

index eba725e41aac..9afa38fd141a 100644
@@ -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");

arch/x86_64.c +1 -33

 	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
 */

makedumpfile.h +2 -3

index a5955ff750e5..13559651feb6 100644
@@ -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
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Hello Pratyush,

Quoted 23 lines

---
arch/x86_64.c | 42 ++++++++---------------------------------- makedumpfile.h | 4 ++--

2 files changed, 10 insertions(+), 36 deletions(-)

arch/x86_64.c +6 -0

index eba725e41aac..9afa38fd141a 100644
@@ -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");

arch/x86_64.c vtop4_x86_64(unsigned long vaddr) · line 221

Quoted 5 lines

arch/x86_64.c +1 -1

@@ -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 <[email protected]>
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.)

Quoted 7 lines

arch/x86_64.c vtop4_x86_64(unsigned long vaddr) · line 221

Quoted 2 lines

arch/x86_64.c +1 -1

-	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:

Quoted 8 lines

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Author: Vivek Goyal <[email protected]>
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:

Quoted 37 lines

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>

Quoted 5 lines

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

Quoted 7 lines · Pratyush Anand

Quoted 7 lines

arch/x86_64.c vtop4_x86_64(unsigned long vaddr) · line 221

Quoted 2 lines

arch/x86_64.c +1 -1

-	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:

Quoted 8 lines

Quoted 8 lines

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Author: Vivek Goyal <[email protected]>
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:

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.

Quoted 44 lines

Quoted 43 lines

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.)

Quoted 7 lines

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

Quoted 22 lines · Baoquan He

Quoted 7 lines · Pratyush Anand

Quoted 7 lines

arch/x86_64.c vtop4_x86_64(unsigned long vaddr) · line 221

Quoted 2 lines

arch/x86_64.c +1 -1

-	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:

Quoted 8 lines

Quoted 8 lines

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Author: Vivek Goyal <[email protected]>
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:

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.

Quoted 2 lines

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:

Quoted 44 lines

Quoted 44 lines

Quoted 43 lines

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.)

Quoted 7 lines

Quoted 7 lines

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

Quoted 26 lines · Baoquan He

Quoted 24 lines · Baoquan He

Quoted 7 lines · Pratyush Anand

Quoted 7 lines

arch/x86_64.c vtop4_x86_64(unsigned long vaddr) · line 221

Quoted 2 lines

arch/x86_64.c +1 -1

-	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:

Quoted 8 lines

Quoted 8 lines

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Author: Vivek Goyal <[email protected]>
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:

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.

Quoted 2 lines

I meant making a judgement:

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

	info->phys_base = 0;	

Quoted 44 lines

Quoted 44 lines

Quoted 44 lines

Quoted 43 lines

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.)

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

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

Quoted 30 lines · Baoquan He

Quoted 28 lines · Baoquan He

Quoted 17 lines · Pratyush Anand

Quoted 7 lines

Quoted 7 lines

Review

Quoted 2 lines

(quoted diff) +1 -1

-	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:

Quoted 8 lines

Quoted 8 lines

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Author: Vivek Goyal <[email protected]>
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:

Quoted 7 lines

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:

Quoted 4 lines

Sorry, should be:
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

Quoted 48 lines

Quoted 48 lines

Quoted 48 lines

Quoted 48 lines

Quoted 38 lines

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>

Quoted 5 lines

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.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Bao, any opnion?

~Pratyush

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 31 lines · On Saturday 10 December 2016 07:03 AM, [email protected] wrote:

Quoted 30 lines · Baoquan He

Quoted 28 lines · Baoquan He

Quoted 17 lines · Pratyush Anand

Quoted 7 lines

Quoted 7 lines

Review

Quoted 2 lines

(quoted diff) +1 -1

-	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:

Quoted 8 lines

Quoted 8 lines

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Author: Vivek Goyal <[email protected]>
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:

Quoted 7 lines

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:

Quoted 8 lines

Quoted 4 lines

Sorry, should be:
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:

arch/x86_64.c +8 -0

index 010ea10..893cd51 100644
@@ -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 ?

Quoted 67 lines

Quoted 31 lines · On Saturday 10 December 2016 07:03 AM, [email protected] wrote:

Quoted 30 lines · Baoquan He

Quoted 28 lines · Baoquan He

Quoted 17 lines · Pratyush Anand

Quoted 7 lines

Quoted 7 lines

Review

Quoted 2 lines

(quoted diff) +1 -1

-	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:

Quoted 8 lines

Quoted 8 lines

commit 1ab60e0f72f71ec54831e525a3e1154f1c092408
Author: Vivek Goyal <[email protected]>
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:

Quoted 7 lines

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:

Quoted 8 lines

Quoted 4 lines

Sorry, should be:
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:

arch/x86_64.c +8 -0

index 010ea10..893cd51 100644
@@ -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) {
 

Quoted 6 lines

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 <[email protected]>
Date:   Wed May 2 19:27:07 2007 +0200

[PATCH] x86-64: Relocatable Kernel Support

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

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.

Changes since V1:
* A bug in patch 1/4 fixed
* Patch log of 2/4 improved to include more number of trials

Pratyush Anand (4):
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(-)

Signature · 7 lines

2.7.4


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

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.

Changes since V1:
* A bug in patch 1/4 fixed
* Patch log of 2/4 improved to include more number of trials

Pratyush Anand (4):
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
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec