[Makedumpfile PATCH V2 0/4] x86_64: Fix page_offset for randomized base enabled

[Makedumpfile PATCH V2 0/4] x86_64: Fix page_offset for randomized base enabled

[Pratyush Anand]

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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Pratyush Anand]

page_offset can always be calculated as 'virtual - physical' for a direct
mapping area on x86. Therefore, remove the version dependent calculation
and use this method.

Suggested-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
 arch/x86_64.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/x86_64.c b/arch/x86_64.c
index ddf7be6bc57b..eba725e41aac 100644
--- a/arch/x86_64.c
+++ b/arch/x86_64.c
@@ -44,6 +44,24 @@ get_xen_p2m_mfn(void)
 	return NOT_FOUND_LONG_VALUE;
 }
 
+static int
+get_page_offset_x86_64(void)
+{
+	int i;
+	unsigned long long phys_start;
+	unsigned long long virt_start;
+
+	for (i = 0; get_pt_load(i, &phys_start, NULL, &virt_start, NULL); i++) {
+		if (virt_start < __START_KERNEL_map) {
+			info->page_offset = virt_start - phys_start;
+			return TRUE;
+		}
+	}
+
+	ERRMSG("Can't get any pt_load to calculate page offset.\n");
+	return FALSE;
+}
+
 int
 get_phys_base_x86_64(void)
 {
@@ -159,10 +177,8 @@ get_versiondep_info_x86_64(void)
 	else
 		info->max_physmem_bits  = _MAX_PHYSMEM_BITS_2_6_31;
 
-	if (info->kernel_version < KERNEL_VERSION(2, 6, 27))
-		info->page_offset = __PAGE_OFFSET_ORIG;
-	else
-		info->page_offset = __PAGE_OFFSET_2_6_27;
+	if (!get_page_offset_x86_64())
+		return FALSE;
 
 	if (info->kernel_version < KERNEL_VERSION(2, 6, 31)) {
 		info->vmalloc_start = VMALLOC_START_ORIG;
-- 
2.7.4


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

[Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[Pratyush Anand]

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 <panand@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


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

RE: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[Atsushi Kumagai]

Hello Pratyush,

>---
> 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 <vgoyal@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


> 	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
>kexec@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec

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

Re: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[Pratyush Anand]

On Friday 09 December 2016 01:05 PM, Atsushi Kumagai wrote:
> Hello Pratyush,
>
>> ---
>> 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 <vgoyal@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.)

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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[bhe]

On 12/09/16 at 03:40pm, Pratyush Anand wrote:
> > > -	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 <vgoyal@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:

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.

> > 
> >   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.)
> 
> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[bhe]

On 12/09/16 at 10:25pm, Baoquan He wrote:
> On 12/09/16 at 03:40pm, Pratyush Anand wrote:
> > > > -	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 <vgoyal@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:
> 
> 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;	

> 
> > > 
> > >   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.)
> > 
> > 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[bhe]

On 12/10/16 at 09:29am, Baoquan He wrote:
> On 12/09/16 at 10:25pm, Baoquan He wrote:
> > On 12/09/16 at 03:40pm, Pratyush Anand wrote:
> > > > > -	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 <vgoyal@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:
> > 
> > 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:
> 

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

> > 
> > > > 
> > > >   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.)
> > > 
> > > 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[Pratyush Anand]

On Saturday 10 December 2016 07:03 AM, bhe@redhat.com wrote:
> On 12/10/16 at 09:29am, Baoquan He wrote:
>> On 12/09/16 at 10:25pm, Baoquan He wrote:
>>> On 12/09/16 at 03:40pm, Pratyush Anand wrote:
>>>>>> -	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 <vgoyal@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:
>>>
>>> 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:
>>
>
> 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

>>>
>>>>>
>>>>>   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.)
>>>>
>>>> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[Atsushi Kumagai]

>On Saturday 10 December 2016 07:03 AM, bhe@redhat.com wrote:
>> On 12/10/16 at 09:29am, Baoquan He wrote:
>>> On 12/09/16 at 10:25pm, Baoquan He wrote:
>>>> On 12/09/16 at 03:40pm, Pratyush Anand wrote:
>>>>>>> -	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 <vgoyal@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:
>>>>
>>>> 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:
>>>
>>
>> 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:

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

>
>~Pratyush
>
>>>>
>>>>>>
>>>>>>   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.)
>>>>>
>>>>> 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
>kexec@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec

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

Re: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[bhe]

On 12/12/16 at 08:40am, Atsushi Kumagai wrote:
> >On Saturday 10 December 2016 07:03 AM, bhe@redhat.com wrote:
> >> On 12/10/16 at 09:29am, Baoquan He wrote:
> >>> On 12/09/16 at 10:25pm, Baoquan He wrote:
> >>>> On 12/09/16 at 03:40pm, Pratyush Anand wrote:
> >>>>>>> -	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 <vgoyal@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:
> >>>>
> >>>> 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:
> >>>
> >>
> >> 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:
> 
> 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 <vgoyal@in.ibm.com>
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

Thanks
Baoquan

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

RE: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values

[Atsushi Kumagai]

>On 12/12/16 at 08:40am, Atsushi Kumagai wrote:
>> >On Saturday 10 December 2016 07:03 AM, bhe@redhat.com wrote:
>> >> On 12/10/16 at 09:29am, Baoquan He wrote:
>> >>> On 12/09/16 at 10:25pm, Baoquan He wrote:
>> >>>> On 12/09/16 at 03:40pm, Pratyush Anand wrote:
>> >>>>>>> -	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 <vgoyal@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:
>> >>>>
>> >>>> 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:
>> >>>
>> >>
>> >> 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:
>>
>> 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 <vgoyal@in.ibm.com>
>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

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

Regards,
Atsushi Kumagai

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

[Makedumpfile PATCH V2 3/4] x86_64: kill is_vmalloc_addr_x86_64()

[Pratyush Anand]

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 <panand@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


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

[Makedumpfile PATCH V2 4/4] x86_64: kill some unused initialization

[Pratyush Anand]

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 <panand@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


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

Re: [Makedumpfile PATCH V2 0/4] x86_64: Fix page_offset for randomized base enabled

[Dave Young]

Pratyush, the patches works for me, thanks~

On 10/31/16 at 01:47pm, Pratyush Anand wrote:
> 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 <cpw@sgi.com>
Date:   Mon Oct 26 23:20:18 2015 +0900

> 
> 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
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

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

RE: [Makedumpfile PATCH V2 0/4] x86_64: Fix page_offset for randomized base enabled

[Atsushi Kumagai]

Hello Pratyush,

>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

The most of concern was the performance degradation, but
there is no degradation in the additional benchmark.
So I decide to merge this patch set into v1.6.1,
thanks for your work.


Regards,
Atsushi Kumagai

>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
>kexec@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec

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