Re: [Qemu-devel] Kernel core dumps from qemu

[Avi Kivity <avi@redhat.com>]

Chris Smith wrote:
> 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.
>   

This looks useful.  I'd suggest a 'format' argument, so we can extend 
this later to dump in non-ELF formats (the Windows native memory dump 
format would be useful).

I suppose the core format handles smp?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.