[PATCH 2/2] Revert "[PATCH V2 1/4] x86_64: Calculate page_offset from pt_load"

[Pratyush Anand]

On Tuesday 23 May 2017 12:55 PM, Hatayama, Daisuke wrote:
> Pratysh,
>
>> -----Original Message-----
>> From: Pratyush Anand [mailto:panand at redhat.com]
>> Sent: Tuesday, May 23, 2017 1:12 PM
>> To: Hatayama, Daisuke <d.hatayama at jp.fujitsu.com>;
>> 'ats-kumagai at wm.jp.nec.com' <ats-kumagai at wm.jp.nec.com>
>> Cc: 'kexec at lists.infradead.org' <kexec at lists.infradead.org>;
>> 'bhe at redhat.com' <bhe at redhat.com>
>> Subject: Re: [PATCH 2/2] Revert "[PATCH V2 1/4] x86_64: Calculate page_offset
>> from pt_load"
>>
>>
>>
>> On Tuesday 23 May 2017 08:53 AM, Pratyush Anand wrote:
>>> Hi Hatayama,
>>>
>>> On Tuesday 23 May 2017 08:24 AM, Hatayama, Daisuke wrote:
>>>> This reverts commit 0c9dd01d8ee2e4ec1821a11f5e174fdba56012b8 because
>>>> the logic works well only on the kdump ELF format. It doesn't work
>>>> well on sadump vmcores and qemu/KVM guest vmcores created by virsh
>>>> dump --memory-only command where info->page_offset results in 0. These
>>>> formats have to depend on kernel version dependency in the current
>>>> situation.
>>>
>>> I do not think that we should just revert it. Revert will break things on
>>> KASLR enabled kernel.
>>>
>>> I have already posted a patch to calculate page_offset when pt_load is not
>>> available.
>>>
>>> http://lists.infradead.org/pipermail/kexec/2017-May/018747.html
>>>
>>> Probably,I can improve that patch in next version so that it takes care of
>>> sadump case as well.
>>>
>>
>> Can you please try following patches from
>> https://github.com/pratyushanand/makedumpfile.git : devel
>>
>> https://github.com/pratyushanand/makedumpfile/commit/ba93c349ac5d097a51c22
>> 1e39816da5fef2e5f58
>
> strtoul() is better than strtol() because info->kaslr_offset is of unsigned long,
> though there's no runtime error in this case.

ok.

>
>> https://github.com/pratyushanand/makedumpfile/commit/241ecc6d96afbf7be6e02
>> f51e882ce5e1e2eb9d0
>
> This patch works fine on sadump vmcores, but doesn't look good on virsh dump --memory-only.
> The vmcore created by virsh dump --memory-only command is written in ELF format.
> Virtual addresses assigned into it differs from the kdump one, not reflecting
> kernel runtime virtual addresses.
>
> Here is a sample readelf output:
>
> # LANG=C readelf -l /root/vmcore-by-virsh-dump
>
> Elf file type is CORE (Core file)
> Entry point 0x0
> There are 7 program headers, starting at offset 64
>
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   NOTE           0x00000000000001c8 0x0000000000000000 0x0000000000000000
>                  0x0000000000000650 0x0000000000000650         0
>   LOAD           0x0000000000000818 0x0000000000000000 0x0000000000000000
>                  0x00000000000a0000 0x00000000000a0000         0
>   LOAD           0x00000000000a0818 0x0000000000000000 0x00000000000a0000
>                  0x0000000000010000 0x0000000000010000         0
>   LOAD           0x00000000000b0818 0x0000000000000000 0x00000000000c0000
>                  0x0000000000020000 0x0000000000020000         0
>   LOAD           0x00000000000d0818 0x0000000000000000 0x00000000000e0000
>                  0x0000000000020000 0x0000000000020000         0
>   LOAD           0x00000000000f0818 0x0000000000000000 0x0000000000100000
>                  0x000000003ff00000 0x000000003ff00000         0
>   LOAD           0x000000003fff0818 0x0000000000000000 0x00000000f0000000
>                  0x0000000001000000 0x0000000001000000         0
>
> How about using QEMU or VMCOREINFO to distinguish QEMU ELF vmcore from
> kdump ELF vmcore?

Thanks for investigating it.

I am not sure why all the virtual address in above PT_LOAD is 0 (which is  
invalid). However, this information can be used similar to how we use  
NOT_PADDR (if virt addresses are always invalid in case of virsh dump).

So what about following updated patch:
https://github.com/pratyushanand/makedumpfile/commit/52387707bb8a8c0c0645215fcbf4eef60c7e4aaf


~Pratyush

>
> I think you know what VMCOREINFO is, and here is QEMU note information example:
>
> # LANG=C readelf -n /root/vmcore
>
> Displaying notes found at file offset 0x000001c8 with length 0x00000650:
>   Owner                 Data size       Description
>   CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
>   CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
>   QEMU                 0x000001b0       Unknown note type: (0x00000000)
>   QEMU                 0x000001b0       Unknown note type: (0x00000000)
>