From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: Stephen Brennan <stephen.s.brennan@oracle.com>
Cc: qemu-devel@nongnu.org, linux-debuggers@vger.kernel.org,
"Omar Sandoval" <osandov@osandov.com>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>
Subject: Re: [PATCH v3 qemu 2/3] dump: Allow directly outputting raw kdump format
Date: Thu, 2 Nov 2023 18:38:09 +0400 [thread overview]
Message-ID: <CAJ+F1CKOWYwrjmLoiQRC=s8XBBE-x2qvABNX1bUVgQdtG-+Q8w@mail.gmail.com> (raw)
In-Reply-To: <20230918233233.1431858-3-stephen.s.brennan@oracle.com>
Hi Stephen
On Tue, Sep 19, 2023 at 3:32 AM Stephen Brennan
<stephen.s.brennan@oracle.com> wrote:
>
> The flattened format (currently output by QEMU) is used by makedumpfile
> only when it is outputting a vmcore to a file which is not seekable. The
> flattened format functions essentially as a set of instructions of the
> form "seek to the given offset, then write the given bytes out".
>
> The flattened format can be reconstructed using makedumpfile -R, or
> makedumpfile-R.pl, but it is a slow process because it requires copying
> the entire vmcore. The flattened format can also be directly read by
> crash, but still, it requires a lengthy reassembly phase.
>
> To sum up, the flattened format is not an ideal one: it should only be
> used on files which are actually not seekable. This is the exact
> strategy which makedumpfile uses, as seen in the implementation of
> "write_buffer()" in makedumpfile [1]. However, QEMU has always used the
> flattened format. For compatibility it is best not to change the default
> output format without warning. So, add a flag to DumpState which changes
> the output to use the normal (i.e. raw) format. This flag will be added
> to the QMP and HMP commands in the next change.
>
> [1]: https://github.com/makedumpfile/makedumpfile/blob/f23bb943568188a2746dbf9b6692668f5a2ac3b6/makedumpfile.c#L5008-L5040
>
> Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
> ---
> dump/dump.c | 32 +++++++++++++++++++++++++-------
> include/sysemu/dump.h | 1 +
> 2 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/dump/dump.c b/dump/dump.c
> index 74071a1565..10aa2c79e0 100644
> --- a/dump/dump.c
> +++ b/dump/dump.c
> @@ -814,6 +814,10 @@ static int write_start_flat_header(DumpState *s)
> MakedumpfileHeader *mh;
> int ret = 0;
>
> + if (s->kdump_raw) {
> + return 0;
> + }
> +
> QEMU_BUILD_BUG_ON(sizeof *mh > MAX_SIZE_MDF_HEADER);
> mh = g_malloc0(MAX_SIZE_MDF_HEADER);
>
> @@ -837,6 +841,10 @@ static int write_end_flat_header(DumpState *s)
> {
> MakedumpfileDataHeader mdh;
>
> + if (s->kdump_raw) {
> + return 0;
> + }
> +
> mdh.offset = END_FLAG_FLAT_HEADER;
> mdh.buf_size = END_FLAG_FLAT_HEADER;
>
> @@ -853,13 +861,21 @@ static int write_buffer(DumpState *s, off_t offset, const void *buf, size_t size
> {
> size_t written_size;
> MakedumpfileDataHeader mdh;
> + loff_t seek_loc;
Any reason to use loff_t over off_t here? It fails to compile on win32
for ex. I can touch on PR commit otherwise.
>
> - mdh.offset = cpu_to_be64(offset);
> - mdh.buf_size = cpu_to_be64(size);
> + if (s->kdump_raw) {
> + seek_loc = lseek(s->fd, offset, SEEK_SET);
> + if (seek_loc == (off_t) -1) {
> + return -1;
> + }
> + } else {
> + mdh.offset = cpu_to_be64(offset);
> + mdh.buf_size = cpu_to_be64(size);
>
> - written_size = qemu_write_full(s->fd, &mdh, sizeof(mdh));
> - if (written_size != sizeof(mdh)) {
> - return -1;
> + written_size = qemu_write_full(s->fd, &mdh, sizeof(mdh));
> + if (written_size != sizeof(mdh)) {
> + return -1;
> + }
> }
>
> written_size = qemu_write_full(s->fd, buf, size);
> @@ -1775,7 +1791,8 @@ static void vmcoreinfo_update_phys_base(DumpState *s)
>
> static void dump_init(DumpState *s, int fd, bool has_format,
> DumpGuestMemoryFormat format, bool paging, bool has_filter,
> - int64_t begin, int64_t length, Error **errp)
> + int64_t begin, int64_t length, bool kdump_raw,
> + Error **errp)
> {
> ERRP_GUARD();
> VMCoreInfoState *vmci = vmcoreinfo_find();
> @@ -1786,6 +1803,7 @@ static void dump_init(DumpState *s, int fd, bool has_format,
> s->has_format = has_format;
> s->format = format;
> s->written_size = 0;
> + s->kdump_raw = kdump_raw;
>
> /* kdump-compressed is conflict with paging and filter */
> if (has_format && format != DUMP_GUEST_MEMORY_FORMAT_ELF) {
> @@ -2168,7 +2186,7 @@ void qmp_dump_guest_memory(bool paging, const char *file,
> dump_state_prepare(s);
>
> dump_init(s, fd, has_format, format, paging, has_begin,
> - begin, length, errp);
> + begin, length, false, errp);
> if (*errp) {
> qatomic_set(&s->status, DUMP_STATUS_FAILED);
> return;
> diff --git a/include/sysemu/dump.h b/include/sysemu/dump.h
> index e27af8fb34..d702854853 100644
> --- a/include/sysemu/dump.h
> +++ b/include/sysemu/dump.h
> @@ -157,6 +157,7 @@ typedef struct DumpState {
> MemoryMappingList list;
> bool resume;
> bool detached;
> + bool kdump_raw;
> hwaddr memory_offset;
> int fd;
>
> --
> 2.39.3
>
--
Marc-André Lureau
next prev parent reply other threads:[~2023-11-02 14:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 23:32 [PATCH v3 qemu 0/3] Allow dump-guest-memory to output standard kdump format Stephen Brennan
2023-09-18 23:32 ` [PATCH v3 qemu 1/3] dump: Pass DumpState to write_ functions Stephen Brennan
2023-09-18 23:32 ` [PATCH v3 qemu 2/3] dump: Allow directly outputting raw kdump format Stephen Brennan
2023-11-02 14:38 ` Marc-André Lureau [this message]
2023-11-02 18:24 ` Stephen Brennan
2023-09-18 23:32 ` [PATCH v3 qemu 3/3] dump: Add command interface for kdump-raw formats Stephen Brennan
2023-09-19 7:53 ` [PATCH v3 qemu 0/3] Allow dump-guest-memory to output standard kdump format Marc-André Lureau
2023-09-19 8:49 ` Daniel P. Berrangé
2023-10-25 22:44 ` Stephen Brennan
2023-10-26 8:16 ` Marc-André Lureau
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='CAJ+F1CKOWYwrjmLoiQRC=s8XBBE-x2qvABNX1bUVgQdtG-+Q8w@mail.gmail.com' \
--to=marcandre.lureau@gmail.com \
--cc=berrange@redhat.com \
--cc=linux-debuggers@vger.kernel.org \
--cc=osandov@osandov.com \
--cc=qemu-devel@nongnu.org \
--cc=stephen.s.brennan@oracle.com \
--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).