* As basis for documenting --format, I recommend the "virsh" manual:

> --format /string/ is used to specify the format of 'memory-only' dump, and
> /string/ can be one of them: /elf/, /kdump-zlib/ (kdump-compressed format with
> zlib-compressed), /kdump-lzo/ (kdump-compressed format with
> lzo-compressed), /kdump-snappy/ (kdump-compressed format with
> snappy-compressed).

* For documenting "dump-guest-memory.py", I recommend two sources as basis:

(1) The commit message of the patch that introduced the script:

  http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3e16d14fd93c

(2) The current built-in help text from the script:

  http://git.qemu.org/?p=qemu.git;a=blob;f=scripts/dump-guest-memory.py

Namely:

> Extract guest vmcore from qemu process coredump.
> 
> The two required arguments are FILE and ARCH:
> FILE identifies the target file to write the guest vmcore to.
> ARCH specifies the architecture for which the core will be generated.
> 
> This GDB command reimplements the dump-guest-memory QMP command in
> python, using the representation of guest memory as captured in the qemu
> coredump. The qemu process that has been dumped must have had the
> command line option "-machine dump-guest-core=on" which is the default.
> 
> For simplicity, the "paging", "begin" and "end" parameters of the QMP
> command are not supported -- no attempt is made to get the guest's
> internal paging structures (ie. paging=false is hard-wired), and guest
> memory is always fully dumped.
> 
> Currently aarch64-be, aarch64-le, X86_64, 386, s390, ppc64-be,
> ppc64-le guests are supported.
> 
> The CORE/NT_PRSTATUS and QEMU notes (that is, the VCPUs' statuses) are
> not written to the vmcore. Preparing these would require context that is
> only present in the KVM host kernel module when the guest is alive. A
> fake ELF note is written instead, only to keep the ELF parser of "crash"
> happy.
> 
> Dependent on how busted the qemu process was at the time of the
> coredump, this command might produce unpredictable results. If qemu
> deliberately called abort(), or it was dumped in response to a signal at
> a halfway fortunate point, then its coredump should be in reasonable
> shape and this command should mostly work.

Thanks!