On Saturday 10 December 2016 07:03 AM, bhe at 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 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: >> > > 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
