Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest

[Dave Anderson]

----- Original Message -----

> > > No, an ELF image of the guest's physical memory.
> >
> > Well then that should be pretty straight forward to support.  Depending upon
> > how similar it would be to the "standard" kdump ELF format, the only other
> > issue is how to determine the physical base address at which the kernel is
> > loaded, in order to be able to translate the mapped kernel-text/static-data
> > virtual region of the x86_64 arch (the __START_KERNEL_map region).
> >
> 
> I guess an elf note would work for that?

Right -- here is an example of a RHEL6 ELF kdump header:

$ readelf -a vmcore
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              CORE (Core file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         6
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0

There are no sections in this file.

There are no sections in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x0000000000000190 0x0000000000000000 0x0000000000000000
                 0x000000000000083c 0x000000000000083c         0
  LOAD           0x00000000000009cc 0xffffffff81000000 0x0000000001000000
                 0x0000000000ba3000 0x0000000000ba3000  RWE    0
  LOAD           0x0000000000ba39cc 0xffff810000000000 0x0000000000000000
                 0x00000000000a0000 0x00000000000a0000  RWE    0
  LOAD           0x0000000000c439cc 0xffff810000100000 0x0000000000100000
                 0x0000000001f00000 0x0000000001f00000  RWE    0
  LOAD           0x0000000002b439cc 0xffff81000a000000 0x000000000a000000
                 0x00000000c5fc2840 0x00000000c5fc2840  RWE    0
  LOAD           0x00000000c8b0620c 0xffff810100000000 0x0000000100000000
                 0x0000000030000000 0x0000000030000000  RWE    0

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Notes at offset 0x00000190 with length 0x0000083c:
  Owner         Data size       Description
  CORE          0x00000150      NT_PRSTATUS (prstatus structure)
  CORE          0x00000150      NT_PRSTATUS (prstatus structure)
  VMCOREINFO            0x0000055b      Unknown note type: (0x00000000)
$

In this example, the phys_base (of zero) can be determined by looking 
at the first PT_LOAD segment, and comparing the PhysAddr and the VirtAddr
values -- given that __START_KERNEL_map region is based at ffffffff800000000.
The remaining physical memory chunks are described by the subsequent 
unity-mapped segments.

The NT_PRSTATUS notes are register dumps of each cpu, where this vmcore
was from a 2-cpu system.  But the crash utility is capable of surviving
without them.  It can also get by without the VMCOREINFO note, which is
primarily there for use by the "makedumpfile" utility, which is used to
compress ELF kdumps and filter out unwanted pages, and then make a different 
dumpfile format entirely.

This may be another stupid question -- but does the guest failure mode
render it incapable of using kdump?

Dave