Hello,

The dump-guest-memory monitor command supports kdump-zlib, as well as a
few other compression options for the kdump format. However, the format
it actually outputs is a variation on that format known as the
"flattened format".  The flattened format is essentially a sequence of
records that give instructions on how to create the final output file.
Each record can be viewed as an instruction: seek to the given offset,
and then write a certain number of bytes to the output file.

The "flattened format" exists to serve makedumpfile in very specific
cases, when there's no filesystem to write a dump to. Then, makedumpfile
may output to stdout or a socket. Since these files aren't seekable, and
buffering the full output would exceed the memory available to it,
makedumpfile is forced to use this flattened format instead.

The flattened format is intended to be reassembled after the fact, using
"makedumpfile -R" or "makedumpfile-R.pl", but this is a lengthy process
because it requires copying the entire file. Crash can read the
flattened format, but this requires a lengthy phase in which it
reassembles / indexes the file. Essentially, I can think of no reason
why a user would want to have the flattened format, when the regular
kdump format is available to them.

So therefore, this patch series changes the behavior of the kdump
creation to match the behavior of makedumpfile: when the output file is
seekable, it will write the normal kdump format. When the output file is
not, it will continue to write the flattened format.

While there could be an argument that the flattened format is more
efficient (in time and/or memory) to create, because it doesn't require
seeking, I'm don't believe this to be the case. Makedumpfile itself is
intended to run in very constrained kexec environments, and it always
writes the regular kdump format, unless its output file is not seekable.
However, I would be open to doing some testing if necessary to verify
the performance is similar.

I do understand that this could raise compatibility concerns. From my
perspective, the "regular kdump format" is strictly more compatible to
other tools than the flattened format. And as I said, I can't think of a
use case where a person would *want* the flattened format. But if it's a
problem, then we could implement a new option to enable the new
behavior.

I've gone ahead and tested the changes and confirmed that the resulting
dumps are still readable via crash with an x86_64 guest.

Thanks for your consideration and review,
Stephen

Stephen Brennan (2):
  dump: Pass DumpState to write_ functions
  dump: Only use the makedumpfile flattened format when necessary

 dump/dump.c           | 68 ++++++++++++++++++++++++++++---------------
 include/sysemu/dump.h |  3 +-
 2 files changed, 46 insertions(+), 25 deletions(-)

-- 
2.39.2