From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Dr. David Alan Gilbert" <dave@treblig.org>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
qemu-devel@nongnu.org, "Laurent Vivier" <lvivier@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Fabiano Rosas" <farosas@suse.de>,
"Eric Blake" <eblake@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [PATCH v2] hw/uefi: add "info ovmf-log" + "query-ovmf-log" monitor commands
Date: Thu, 9 Oct 2025 13:00:14 +0100 [thread overview]
Message-ID: <aOejzqM74_NiOHJJ@redhat.com> (raw)
In-Reply-To: <aOefUN5_bSKjWPLc@gallifrey>
On Thu, Oct 09, 2025 at 11:41:04AM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > On Thu, Oct 09, 2025 at 01:56:09AM +0000, Dr. David Alan Gilbert wrote:
> > > * Gerd Hoffmann (kraxel@redhat.com) wrote:
> > > > Starting with the edk2-stable202508 tag OVMF (and ArmVirt too) have
> > > > optional support for logging to a memory buffer. There is guest side
> > > > support -- for example in linux kernels v6.17+ -- to read that buffer.
> > > > But that might not helpful if your guest stops booting early enough that
> > > > guest tooling can not be used yet. So host side support to read that
> > > > log buffer is a useful thing to have.
> > > >
> > > > This patch implements both qmp and hmp monitor commands to read the
> > > > firmware log.
> > > >
> > > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > >
> > > I'm OK with that, but I wonder if it would be better to have a command
> > > that wrote the buffer to a file rather than displaying it directly; I don't
> > > think we normally have anything else which outputs that much raw guest
> > > provided data directly.
> > > I assume when it goes wrong you end up with random unprintable junk in
> > > the buffer.
> >
> > 128 KB is on the high side, but is not terrible. Libvirt (arbitrarily)
> > caps a QMP reply at 10 MB. Libvirt is going to want to send this on to
> > the client app and will likely do that streaming in memory, so having
> > it iin a file is not required from our POV.
> >
> > IIRC, some of the query-block command replies can get insanely huge
> > when the qcow2 chain is very long.
>
> OK, what about sanitisation - if that text contains random binary what happens,
> or should we make sure it's sanitised?
As prior art, the QGA 'guest-exec' command will return stdout/stderr
of the command in base64 format. The downside is that it is bloated
in size, but it is at least safe wrt JSON encoding. The HMP command
could still dump the raw data IMHO, as that's human facing and base64
is horrible for human consumption.
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 :|
next prev parent reply other threads:[~2025-10-09 12:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 13:52 [PATCH v2] hw/uefi: add "info ovmf-log" + "query-ovmf-log" monitor commands Gerd Hoffmann
2025-10-08 6:32 ` Markus Armbruster
2025-10-08 7:09 ` Daniel P. Berrangé
2025-10-09 1:56 ` Dr. David Alan Gilbert
2025-10-09 7:13 ` Daniel P. Berrangé
2025-10-09 11:41 ` Dr. David Alan Gilbert
2025-10-09 12:00 ` Daniel P. Berrangé [this message]
2025-10-09 12:41 ` Gerd Hoffmann
2025-10-09 13:17 ` Dr. David Alan Gilbert
2025-10-09 14:06 ` 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=aOejzqM74_NiOHJJ@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=dave@treblig.org \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=farosas@suse.de \
--cc=kraxel@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=wangyanan55@huawei.com \
--cc=zhao1.liu@intel.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).