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) >
