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

[Hatayama, Daisuke]

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.
 
> 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?

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)