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

[Pratyush Anand <panand@redhat.com>]

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