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

[Wen Congyang <wency@cn.fujitsu.com>]

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