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

[bhe at redhat.com]

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