At 10/24/2011 11:58 PM, Dave Anderson Write: > > > ----- 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:
Hi, Jan Is gdb standard core file like the following format? Does gdb support this format? If yes, I think the dump command can output the guest physical memory in the following format, and we can use both gdb and crash to analyze it. > > $ 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? Guest failure mode? I do not what does it mean. But 'virsh dump' can be used when kdump fails or kdump service is not started. Thanks Wen Congyang > > Dave > >
