From: Pratyush Anand <panand@redhat.com>
To: Atsushi Kumagai <ats-kumagai@wm.jp.nec.com>,
"bhe@redhat.com" <bhe@redhat.com>
Cc: "dyoung@redhat.com" <dyoung@redhat.com>,
"louis.bouchard@canonical.com" <louis.bouchard@canonical.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values
Date: Fri, 9 Dec 2016 15:40:21 +0530 [thread overview]
Message-ID: <3d3fcf63-eb95-9adb-b645-9f906d5f900f@redhat.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9701E87E88@BPXM01GP.gisp.nec.co.jp>
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
next prev parent reply other threads:[~2016-12-09 10:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-31 8:17 [Makedumpfile PATCH V2 0/4] x86_64: Fix page_offset for randomized base enabled Pratyush Anand
2016-10-31 8:17 ` [Makedumpfile PATCH V2 1/4] x86_64: Calculate page_offset from pt_load Pratyush Anand
2016-10-31 8:17 ` [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values Pratyush Anand
2016-12-09 7:35 ` Atsushi Kumagai
2016-12-09 10:10 ` Pratyush Anand [this message]
2016-12-09 14:25 ` bhe
2016-12-10 1:29 ` bhe
2016-12-10 1:33 ` bhe
2016-12-10 6:20 ` Pratyush Anand
2016-12-12 8:40 ` Atsushi Kumagai
2016-12-12 9:50 ` bhe
2016-12-13 7:03 ` Atsushi Kumagai
2016-10-31 8:17 ` [Makedumpfile PATCH V2 3/4] x86_64: kill is_vmalloc_addr_x86_64() Pratyush Anand
2016-10-31 8:17 ` [Makedumpfile PATCH V2 4/4] x86_64: kill some unused initialization Pratyush Anand
2016-11-01 5:34 ` [Makedumpfile PATCH V2 0/4] x86_64: Fix page_offset for randomized base enabled Dave Young
2016-11-04 10:35 ` Atsushi Kumagai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d3fcf63-eb95-9adb-b645-9f906d5f900f@redhat.com \
--to=panand@redhat.com \
--cc=ats-kumagai@wm.jp.nec.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=louis.bouchard@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.