Re: [PATCH v2 qemu 3/3] dump: Add qmp argument "reassembled"

Stephen Brennan <[email protected]>
Newsgroups org.kernel.vger.linux-debuggers,org.nongnu.qemu-devel
Message-ID <[email protected]>
Daniel P. Berrangé <[email protected]> writes:
> On Wed, Sep 13, 2023 at 06:03:15PM -0700, Stephen Brennan wrote:
>> This can be used from QMP command line as "-R" to mirror the
>> corresponding flag for makedumpfile. This enables the kdump_reassembled
>> flag introduced in the previous patch.
>> 
>> Signed-off-by: Stephen Brennan <[email protected]>
>> ---
>>  dump/dump-hmp-cmds.c |  8 +++++++-
>>  dump/dump.c          | 12 +++++++++++-
>>  hmp-commands.hx      |  7 +++++--
>>  qapi/dump.json       | 14 +++++++++++++-
>>  4 files changed, 36 insertions(+), 5 deletions(-)
>
>> diff --git a/qapi/dump.json b/qapi/dump.json
>> index 4ae1f722a9..9cc7c3ea93 100644
>> --- a/qapi/dump.json
>> +++ b/qapi/dump.json
>> @@ -69,6 +69,18 @@
>>  #     to dump all guest's memory, please specify the start @begin and
>>  #     @length
>>  #
>> +# @reassembled: if false (the default), the kdump output formats will use the
>> +#     "makedumpfile flattened" variant of the format, which is less broadly
>> +#     compatible with analysis tools. The flattened dump can be reassembled
>> +#     after the fact using the command "makedumpfile -R". If true, Qemu
>> +#     attempts to generate the standard kdump format. This requires a
>> +#     seekable file as output -- if the output file is not seekable, then
>> +#     the flattened format is still generated. The standard format is more
>> +#     broadly compatible with debugging tools, but generating it requires a
>> +#     seekable output file descriptor, and could use more system memory due
>> +#     to page cache utilization. This should be left unspecified for non-kdump
>> +#     output formats.
>> +#
>>  # @format: if specified, the format of guest memory dump.  But non-elf
>>  #     format is conflict with paging and filter, ie.  @paging, @begin
>>  #     and @length is not allowed to be specified with non-elf @format
>> @@ -89,7 +101,7 @@
>>  { 'command': 'dump-guest-memory',
>>    'data': { 'paging': 'bool', 'protocol': 'str', '*detach': 'bool',
>>              '*begin': 'int', '*length': 'int',
>> -            '*format': 'DumpGuestMemoryFormat'} }
>> +            '*reassembled': 'bool', '*format': 'DumpGuestMemoryFormat'} }
>
> The 'reassembled' flag is changing the meaning of 3 out of the 5
> 'format' enum values. IMHO, we should just be adding new formats
> instead of changing the meaning of existing formats. It is a shame
> we have the current 'kdump' naming prefix, but we're stuck with
> that for backwards compat, we need a new prefix. I'd suggest
> 'kdump-raw'. eg
>
> #
> # @DumpGuestMemoryFormat:
> #
> # An enumeration of guest-memory-dump's format.
> #
> # @elf: elf format
> #
> # @kdump-zlib: makedumpfile flattened, kdump-compressed format with zlib-compressed
> #
> # @kdump-lzo: makedumpfile flattened, kdump-compressed format with lzo-compressed
> #
> # @kdump-snappy: makedumpfile flattened, kdump-compressed format with snappy-compressed
> #
> # @kdump-raw-zlib: raw assembled kdump-compressed format with zlib-compressed (since 8.2)
> #
> # @kdump-raw-lzo: raw assembled kdump-compressed format with lzo-compressed (since 8.2)
> #
> # @kdump-raw-snappy: raw assembled kdump-compressed format with snappy-compressed (since 8.2)
> #
> # @win-dmp: Windows full crashdump format, can be used instead of ELF
> #     converting (since 2.13)
> #
> # Since: 2.0
> ##
> { 'enum': 'DumpGuestMemoryFormat',
>   'data': [ 'elf',
>             'kdump-zlib', 'kdump-lzo', 'kdump-snappy',
>             'kdump-raw-zlib', 'kdump-raw-lzo', 'kdump-raw-snappy',
>             'win-dmp' ] }

Hi Daniel,

Sure, I'll go ahead and use this approach instead. One question: I see
that this generates the enumeration DumpGuestMemoryFormat in
qapi-types-dump.h. I just wanted to double-check if there's any ABI
considerations for the numbering of this enum? Inserting kdump-raw-* at
this point would result in 'win-dmp' getting a different numbering, and
it seems possible that the API/ABI which libvirt uses might depend on
the enumeration values not changing. E.G. if libvirt is built against
one version of Qemu and then used with a different one.

Thanks,
Stephen

> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.