Re: [Qemu-devel] [PATCH 0/9] Make monitor command 'dump-guest-memory' dump in kdump-compressed format

[HATAYAMA Daisuke]

Please add CC list to Kumagai-san, makedumpfile maintainer, and Dave
Anderson in order to let them know this development.

(2013/05/07 16:16), Qiao Nuohan wrote:
> Hi, all
> 
> Command 'dump-guest-memory' was introduced to dump guest's memory. But the
> vmcore's format is only elf32 or elf64. The message is here:
> http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03379.html
> 
> These patches are used to make 'dump-guest-memory' be able to dump guest's
> memory in kdump-compressed format. Then vmcore can be much smaller, and
> easily be delivered.
> 

It should be stressed here that compression feature is *regression*.

> Note, similar to 'dump-guest-memory':
> 1. The guest should be x86 or x86_64. The other arch is not supported now.
> 2. If the OS is in the second kernel, gdb may not work well, and crash can
>     work by specifying '--machdep phys_addr=xxx' in the command line. The
>     reason is that the second kernel will update the page table, and we can
>     not get the page table for the first kernel.
> 3. The cpu's state is stored in QEMU note.
> 4. The vmcore are able to be compressed with zlib, lzo or snappy. zlib is
>     available by default, and option '--enable-lzo' or '--enable-snappy'
>     should be used with configure to make lzo or snappy available.
> 
>    the kdump-compressed format is:

Rather than detail of format, qemu people should want to know more
general information about kdump-compressed format. They should think
"What this format?" now. At least the following is needed: the
kdump-compressed format is *linux specific* *linux standard* crash dump
format used in kdump framework.

>                                                 File offset
>    +------------------------------------------+ 0x0
>    |    main header (struct disk_dump_header) |
>    |------------------------------------------+ block 1
>    |    sub header (struct kdump_sub_header)  |
>    |------------------------------------------+ block 2
>    |            1st-dump_bitmap               |
>    |------------------------------------------+ block 2 + X blocks
>    |            2nd-dump_bitmap               | (aligned by block)
>    |------------------------------------------+ block 2 + 2 * X blocks
>    |  page desc for pfn 0 (struct page_desc)  | (aligned by block)
>    |  page desc for pfn 1 (struct page_desc)  |
>    |                    :                     |
>    |  page desc for pfn Z (struct page_desc)  |
>    |------------------------------------------| (not aligned by block)
>    |         page data (pfn 0)                |
>    |         page data (pfn 1)                |
>    |                        :                 |
>    |         page data (pfn Z)                |
>    +------------------------------------------+ offset_eraseinfo
>    |                    :                     |
>    +------------------------------------------+

Layout itself is important information. Not only describing this here,
it's better to put it anywhere of source code or point at IMPLEMENTATION
file in makedumpfile which describes orignal spec.

-- 
Thanks.
HATAYAMA, Daisuke