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

["bhe@redhat.com" <bhe@redhat.com>]

On 12/12/16 at 08:40am, Atsushi Kumagai wrote:
> >On Saturday 10 December 2016 07:03 AM, bhe@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@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.
> 
> 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 <vgoyal@in.ibm.com>
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