linux-debuggers.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Brennan <stephen.s.brennan@oracle.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, linux-debuggers@vger.kernel.org,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	"Omar Sandoval" <osandov@osandov.com>,
	"Thomas Huth" <thuth@redhat.com>
Subject: Re: [PATCH v2 qemu 3/3] dump: Add qmp argument "reassembled"
Date: Mon, 18 Sep 2023 10:34:30 -0700	[thread overview]
Message-ID: <87msxjxu55.fsf@oracle.com> (raw)
In-Reply-To: <ZQg9qjdMZL4Tt6EN@redhat.com>

Daniel P. Berrangé <berrange@redhat.com> 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 <stephen.s.brennan@oracle.com>
>> ---
>>  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 :|

  reply	other threads:[~2023-09-18 17:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-14  1:03 [PATCH v2 qemu 0/3] Allow dump-guest-memory to output standard kdump format Stephen Brennan
2023-09-14  1:03 ` [PATCH v2 qemu 1/3] dump: Pass DumpState to write_ functions Stephen Brennan
2023-09-14  1:03 ` [PATCH v2 qemu 2/3] dump: Allow directly outputting reassembled kdumps Stephen Brennan
2023-09-18 11:13   ` Marc-André Lureau
2023-09-14  1:03 ` [PATCH v2 qemu 3/3] dump: Add qmp argument "reassembled" Stephen Brennan
2023-09-18 11:15   ` Marc-André Lureau
2023-09-18 12:08   ` Daniel P. Berrangé
2023-09-18 17:34     ` Stephen Brennan [this message]
2023-09-18 17:43       ` Daniel P. Berrangé
2023-09-18 12:10 ` [PATCH v2 qemu 0/3] Allow dump-guest-memory to output standard kdump format Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87msxjxu55.fsf@oracle.com \
    --to=stephen.s.brennan@oracle.com \
    --cc=berrange@redhat.com \
    --cc=linux-debuggers@vger.kernel.org \
    --cc=marcandre.lureau@gmail.com \
    --cc=osandov@osandov.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).