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