RE: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values
>On 12/12/16 at 08:40am, Atsushi Kumagai wrote:
>> >On Saturday 10 December 2016 07:03 AM, b...@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
>> >> 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 = 0x10" from my
>> >> vmcore:
>>
>> This is really awkward. Checked code, found PAGE_OFFSET is
>> 0x8100 before 2.6.26, then changed to 0x8800
>> 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 == 0x8100 && !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
>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
Re: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values
On 12/12/16 at 08:40am, Atsushi Kumagai wrote:
> >On Saturday 10 December 2016 07:03 AM, b...@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
> >> 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 = 0x10" from my
> >> vmcore:
>
> This is really awkward. Checked code, found PAGE_OFFSET is
> 0x8100 before 2.6.26, then changed to 0x8800
> 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 == 0x8100 && !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
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
>On Saturday 10 December 2016 07:03 AM, b...@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
>> 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 = 0x10" from my vmcore:
This is really awkward. Checked code, found PAGE_OFFSET is
0x8100 before 2.6.26, then changed to 0x8800
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 == 0x8100 && !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
>> FileSizMemSiz Flags Align
>> NOTE 0x0190 0x 0x
>> 0x0590 0x0590 0
>> LOAD 0x0720 0x8000
>> 0x0010// CONFIG_PHYSICAL_START = 0x10
>> 0x008b2000 0x008b2000 RWE0
>> LOAD 0x008b2720 0x8100 0x
>> 0x000a 0x000a RWE0
>> LOAD 0x00952720 0x8110 0x0010
>> 0x00f0 0x00f0 RWE0
>> LOAD 0x01852720 0x81000500 0x0500
>> 0xcaf7 0xcaf7 RWE0
>> LOAD 0xcc7c2720 0x8101 0x0001
>> 0x7000 0x7000 RWE0
>>
>> Of course we shouldn't use that invalid phys_base:
>>
>> crash> sym init_level4_pgt
>> 80101000 (T) init_level4_pgt
>> crash> vtop 80101000
>> VIRTUAL PHYSICAL
>> 80101000 101000 // just "VIRTUAL -
>> __START_KERNEL_map"
>>
>> PML4 DIRECTORY: 80101000
>> PAGE DIRECTORY: 103027
>> PUD: 103ff0 => 105027
>> PMD: 105000 => 1e3
>> PAGE: 0 (2MB)
>>
>> PTE PHYSICAL FLAGS
>> 1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL)
>>
>> PAGEPHYSICAL MAPPING INDEX CNT FLAGS
>> 81000500483810100000 1 400
>> crash>
>>
>> At first I thought about setting 0 to phys_base if the kernel is
>>
Re: [Makedumpfile PATCH V2 2/4] x86_64: translate all VA to PA using page table values
On Saturday 10 December 2016 07:03 AM, b...@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 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 = 0x10" from my vmcore: This is really awkward. Checked code, found PAGE_OFFSET is 0x8100 before 2.6.26, then changed to 0x8800 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 == 0x8100 && !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 FileSizMemSiz Flags Align NOTE 0x0190 0x 0x 0x0590 0x0590 0 LOAD 0x0720 0x8000 0x0010// CONFIG_PHYSICAL_START = 0x10 0x008b2000 0x008b2000 RWE0 LOAD 0x008b2720 0x8100 0x 0x000a 0x000a RWE0 LOAD 0x00952720 0x8110 0x0010 0x00f0 0x00f0 RWE0 LOAD 0x01852720 0x81000500 0x0500 0xcaf7 0xcaf7 RWE0 LOAD 0xcc7c2720 0x8101 0x0001 0x7000 0x7000 RWE0 Of course we shouldn't use that invalid phys_base: crash> sym init_level4_pgt 80101000 (T) init_level4_pgt crash> vtop 80101000 VIRTUAL PHYSICAL 80101000 101000 // just "VIRTUAL - __START_KERNEL_map" PML4 DIRECTORY: 80101000 PAGE DIRECTORY: 103027 PUD: 103ff0 => 105027 PMD: 105000 => 1e3 PAGE: 0 (2MB) PTE PHYSICAL FLAGS 1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL) PAGEPHYSICAL MAPPING INDEX CNT FLAGS 81000500483810100000 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
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 > > > > 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 = 0x10" from my vmcore: > > > > This is really awkward. Checked code, found PAGE_OFFSET is > > 0x8100 before 2.6.26, then changed to 0x8800 > > 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 == 0x8100 && !info->kernel_version > KERNEL_VERSION(2, 6, 21)) info->phys_base = 0; > > > > > > > > > > Type Offset VirtAddr PhysAddr > > > > FileSizMemSiz Flags Align > > > > NOTE 0x0190 0x > > > > 0x > > > > 0x0590 0x0590 0 > > > > LOAD 0x0720 0x8000 > > > > 0x0010// CONFIG_PHYSICAL_START = 0x10 > > > > 0x008b2000 0x008b2000 RWE0 > > > > LOAD 0x008b2720 0x8100 > > > > 0x > > > > 0x000a 0x000a RWE0 > > > > LOAD 0x00952720 0x8110 > > > > 0x0010 > > > > 0x00f0 0x00f0 RWE0 > > > > LOAD 0x01852720 0x81000500 > > > > 0x0500 > > > > 0xcaf7 0xcaf7 RWE0 > > > > LOAD 0xcc7c2720 0x8101 > > > > 0x0001 > > > > 0x7000 0x7000 RWE0 > > > > > > > > Of course we shouldn't use that invalid phys_base: > > > > > > > > crash> sym init_level4_pgt > > > > 80101000 (T) init_level4_pgt > > > > crash> vtop 80101000 > > > > VIRTUAL PHYSICAL > > > > 80101000 101000 // just "VIRTUAL - > > > > __START_KERNEL_map" > > > > > > > > PML4 DIRECTORY: 80101000 > > > > PAGE DIRECTORY: 103027 > > > > PUD: 103ff0 => 105027 > > > > PMD: 105000 => 1e3 > > > > PAGE: 0 (2MB) > > > > > > > > PTE PHYSICAL FLAGS > > > > 1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL) > > > > > > > > PAGEPHYSICAL MAPPING INDEX CNT FLAGS > > > > 81000500483810100000 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
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 > > > 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 = 0x10" from my vmcore: > > This is really awkward. Checked code, found PAGE_OFFSET is > 0x8100 before 2.6.26, then changed to 0x8800 > 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 == 0x8100 && info->kernel_version > KERNEL_VERSION(2, 6, 21)) info->phys_base = 0; > > > > > > > Type Offset VirtAddr PhysAddr > > > FileSizMemSiz Flags Align > > > NOTE 0x0190 0x 0x > > > 0x0590 0x0590 0 > > > LOAD 0x0720 0x8000 0x0010 > > >// CONFIG_PHYSICAL_START = 0x10 > > > 0x008b2000 0x008b2000 RWE0 > > > LOAD 0x008b2720 0x8100 0x > > > 0x000a 0x000a RWE0 > > > LOAD 0x00952720 0x8110 0x0010 > > > 0x00f0 0x00f0 RWE0 > > > LOAD 0x01852720 0x81000500 0x0500 > > > 0xcaf7 0xcaf7 RWE0 > > > LOAD 0xcc7c2720 0x8101 0x0001 > > > 0x7000 0x7000 RWE0 > > > > > > Of course we shouldn't use that invalid phys_base: > > > > > > crash> sym init_level4_pgt > > > 80101000 (T) init_level4_pgt > > > crash> vtop 80101000 > > > VIRTUAL PHYSICAL > > > 80101000 101000 // just "VIRTUAL - > > > __START_KERNEL_map" > > > > > > PML4 DIRECTORY: 80101000 > > > PAGE DIRECTORY: 103027 > > > PUD: 103ff0 => 105027 > > > PMD: 105000 => 1e3 > > > PAGE: 0 (2MB) > > > > > > PTE PHYSICAL FLAGS > > > 1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL) > > > > > > PAGEPHYSICAL MAPPING INDEX CNT FLAGS > > > 81000500483810100000 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
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 > > 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 = 0x10" from my vmcore: This is really awkward. Checked code, found PAGE_OFFSET is 0x8100 before 2.6.26, then changed to 0x8800 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 > > FileSizMemSiz Flags Align > > NOTE 0x0190 0x 0x > > 0x0590 0x0590 0 > > LOAD 0x0720 0x8000 0x0010 > > // CONFIG_PHYSICAL_START = 0x10 > > 0x008b2000 0x008b2000 RWE0 > > LOAD 0x008b2720 0x8100 0x > > 0x000a 0x000a RWE0 > > LOAD 0x00952720 0x8110 0x0010 > > 0x00f0 0x00f0 RWE0 > > LOAD 0x01852720 0x81000500 0x0500 > > 0xcaf7 0xcaf7 RWE0 > > LOAD 0xcc7c2720 0x8101 0x0001 > > 0x7000 0x7000 RWE0 > > > > Of course we shouldn't use that invalid phys_base: > > > > crash> sym init_level4_pgt > > 80101000 (T) init_level4_pgt > > crash> vtop 80101000 > > VIRTUAL PHYSICAL > > 80101000 101000 // just "VIRTUAL - > > __START_KERNEL_map" > > > > PML4 DIRECTORY: 80101000 > > PAGE DIRECTORY: 103027 > > PUD: 103ff0 => 105027 > > PMD: 105000 => 1e3 > > PAGE: 0 (2MB) > > > > PTE PHYSICAL FLAGS > > 1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL) > > > > PAGEPHYSICAL MAPPING INDEX CNT FLAGS > > 81000500483810100000 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
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
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 = 0x10" from my vmcore:
Type Offset VirtAddr PhysAddr
FileSizMemSiz Flags Align
NOTE 0x0190 0x 0x
0x0590 0x0590 0
LOAD 0x0720 0x8000 0x0010//
CONFIG_PHYSICAL_START = 0x10
0x008b2000 0x008b2000 RWE0
LOAD 0x008b2720 0x8100 0x
0x000a 0x000a RWE0
LOAD 0x00952720 0x8110 0x0010
0x00f0 0x00f0 RWE0
LOAD 0x01852720 0x81000500 0x0500
0xcaf7 0xcaf7 RWE0
LOAD 0xcc7c2720 0x8101 0x0001
0x7000 0x7000 RWE0
Of course we shouldn't use that invalid phys_base:
crash> sym init_level4_pgt
80101000 (T) init_level4_pgt
crash> vtop 80101000
VIRTUAL PHYSICAL
80101000 101000 // just "VIRTUAL - __START_KERNEL_map"
PML4 DIRECTORY: 80101000
PAGE DIRECTORY: 103027
PUD: 103ff0 => 105027
PMD: 105000 => 1e3
PAGE: 0 (2MB)
PTE PHYSICAL FLAGS
1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL)
PAGEPHYSICAL MAPPING INDEX CNT FLAGS
81000500483810100000 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
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
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 = 0x10" from my vmcore:
Type Offset VirtAddr PhysAddr
FileSizMemSiz Flags Align
NOTE 0x0190 0x 0x
0x0590 0x0590 0
LOAD 0x0720 0x8000 0x0010//
CONFIG_PHYSICAL_START = 0x10
0x008b2000 0x008b2000 RWE0
LOAD 0x008b2720 0x8100 0x
0x000a 0x000a RWE0
LOAD 0x00952720 0x8110 0x0010
0x00f0 0x00f0 RWE0
LOAD 0x01852720 0x81000500 0x0500
0xcaf7 0xcaf7 RWE0
LOAD 0xcc7c2720 0x8101 0x0001
0x7000 0x7000 RWE0
Of course we shouldn't use that invalid phys_base:
crash> sym init_level4_pgt
80101000 (T) init_level4_pgt
crash> vtop 80101000
VIRTUAL PHYSICAL
80101000 101000 // just "VIRTUAL - __START_KERNEL_map"
PML4 DIRECTORY: 80101000
PAGE DIRECTORY: 103027
PUD: 103ff0 => 105027
PMD: 105000 => 1e3
PAGE: 0 (2MB)
PTE PHYSICAL FLAGS
1e3 0 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL)
PAGEPHYSICAL MAPPING INDEX CNT FLAGS
81000500483810100000 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/makedu
