[Qemu-devel] Kernel core dumps from qemu

[Chris Smith <xsmith@hp.com>]

Hello.

I have been looking at adding a monitor command

    (qemu) dump <file>

to produce a snapshot kernel core dump similar to /proc/vmcore.

There is nothing wrong with kdump in the guest, but having 
a host dumper (in addition) would have some advantages:

 - saves 64 meg in each Linux guest (reserved for dump-capture kernel)

 - can write a snapshot dump and continue, kdump cannot
   (can automatically dump on OOPS as well as panic)

 - produces dump in the host filesystem, easier for management tools

 - Xen has this, virsh supports this

 - not limited to Linux guests

I'll outline some specific ideas and issues.  

My question is: might qemu/KVM be interested in adopting something like this?
In due course.

Ok... kdump vmcores are 64-bit ELF core files, even on 32-bit i386.
So too it should be with host dumps.

Linux-x64 maps physical memory twice, at 0xffff880000000000
and at 0xffffffff80000000.  An ELF dump that gives those addresses
both pointing to a copy of phys_ram[] is satisfactory to crash and gdb.

It would be unwholesome for qemu to know those constants (__PAGE_OFFSET
and __START_KERNEL_map).  Worse than unwholesome, __PAGE_OFFSET recently
changed.

So: qemu writes an ELF dump, but without providing virtual addresses.
Crash will be able to read this as is.  For others, a tool can examine
System.map or vmlinux and fix up the vmcore.  For ease of use, piping
the dump through the tool can have some easy syntax.

This also handles Windows dumps, Solaris dumps, DMX dumps, and so on.
qemu provides the info it has, and need not worry about the formatting.

Registers are needed too.  

vmcores have elf NT_PRSTATUS notes with the registers filled in and
the rest zero.  (Except current->pid which I hope isn't needed because
qemu can't do it.)

So, NT_PRSTATUS is reasonable.  Also, since it's inevitably 
machine dependent, CPUState plus a version number would allow access
to pretty much everything.  Or the standard thing would be pt_regs.
(It is easy to add new note types.)

Last, there should be a note giving the version number of the spec.

Comments appreciated.