All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"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>,
	"Dr. David Alan Gilbert" <dave@treblig.org>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [PATCH v4 2/2] hw/uefi/ovmf-log: add maxsize parameter
Date: Tue, 14 Oct 2025 14:48:01 +0200	[thread overview]
Message-ID: <874is1odj2.fsf@pond.sub.org> (raw)
In-Reply-To: <20251013104954.250166-3-kraxel@redhat.com> (Gerd Hoffmann's message of "Mon, 13 Oct 2025 12:49:54 +0200")

Gerd Hoffmann <kraxel@redhat.com> writes:

> Allow limiting the amount of log output sent.  Allow up to 1 MiB.
> In case the guest log buffer is larger than 1 MiB limit the output
> instead of throwing an error.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hw/uefi/ovmf-log.c   | 40 ++++++++++++++++++++++++++++++++--------
>  hmp-commands-info.hx |  5 ++---
>  qapi/machine.json    |  3 +++
>  3 files changed, 37 insertions(+), 11 deletions(-)
>
> diff --git a/hw/uefi/ovmf-log.c b/hw/uefi/ovmf-log.c
> index f03e47a290d6..9d9dc7b0d8d5 100644
> --- a/hw/uefi/ovmf-log.c
> +++ b/hw/uefi/ovmf-log.c
> @@ -19,6 +19,7 @@
>  #include "qapi/error.h"
>  #include "qapi/type-helpers.h"
>  #include "qapi/qapi-commands-machine.h"
> +#include "qobject/qdict.h"
>  
>  
>  /* ----------------------------------------------------------------------- */
> @@ -167,7 +168,8 @@ static void handle_ovmf_log_range(GString *out,
>      }
>  }
>  
> -FirmwareLog *qmp_query_firmware_log(Error **errp)
> +FirmwareLog *qmp_query_firmware_log(bool have_maxsize, uint64_t maxsize,
> +                                    Error **errp)
>  {
>      MEM_DEBUG_LOG_HDR header;
>      dma_addr_t offset, base;
> @@ -187,18 +189,38 @@ FirmwareLog *qmp_query_firmware_log(Error **errp)
>          return NULL;
>      }
>  
> -    if (header.DebugLogSize > MiB) {
> -        /* default size is 128k (32 pages), allow up to 1M */
> -        error_setg(errp, "firmware log: log buffer is too big");
> -        return NULL;
> -    }
> -
>      if (header.DebugLogHeadOffset > header.DebugLogSize ||
>          header.DebugLogTailOffset > header.DebugLogSize) {
>          error_setg(errp, "firmware log: invalid header");
>          return NULL;
>      }
>  
> +    if (!have_maxsize) {
> +        maxsize = MiB;
> +    }
> +    if (maxsize > MiB) {
> +        maxsize = MiB;

Silently "fixing" the user's instructions is rarely a good idea.  Either
don't limit the argument (if the user asks for rope...), or make
exceeding the limit an error.

> +    }
> +
> +    /* adjust header.DebugLogHeadOffset so we rezturn at most maxsize bytes */
> +    if (header.DebugLogHeadOffset > header.DebugLogTailOffset) {
> +        /* wrap around */
> +        if (header.DebugLogTailOffset > maxsize) {
> +            header.DebugLogHeadOffset = header.DebugLogTailOffset - maxsize;
> +        } else {
> +            uint64_t maxchunk = maxsize - header.DebugLogTailOffset;
> +            if (header.DebugLogSize > maxchunk &&
> +                header.DebugLogHeadOffset < header.DebugLogSize - maxchunk) {
> +                header.DebugLogHeadOffset = header.DebugLogSize - maxchunk;
> +            }
> +        }
> +    } else {
> +        if (header.DebugLogTailOffset > maxsize &&
> +            header.DebugLogHeadOffset < header.DebugLogTailOffset - maxsize) {
> +            header.DebugLogHeadOffset = header.DebugLogTailOffset - maxsize;
> +        }
> +    }
> +
>      base = offset + header.HeaderSize;
>      if (header.DebugLogHeadOffset > header.DebugLogTailOffset) {
>          /* wrap around */
> @@ -237,8 +259,10 @@ void hmp_info_firmware_log(Monitor *mon, const QDict *qdict)
>  {
>      Error *errp = NULL;
>      FirmwareLog *log;
> +    int64_t maxsize;
>  
> -    log = qmp_query_firmware_log(&errp);
> +    maxsize = qdict_get_try_int(qdict, "maxsize", -1);
> +    log = qmp_query_firmware_log(maxsize != -1, (uint64_t)maxsize, &errp);

Put a pin here.

>      if (errp)  {
>          hmp_handle_error(mon, errp);
>          return;
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index 257015f0b403..db03d88d3c74 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -980,11 +980,10 @@ ERST
>  
>      {
>          .name       = "firmware-log",
> -        .args_type  = "",
> -        .params     = "",
> +        .args_type  = "maxsize:i?",

args_type 'i' is a 32 bit signed integer, so this gives us 31 bits.
Suffices.  But what happens when the user specifies a negative number?
I think hmp_info_firmware_log() treats -1 as if the parameter was
omitted.  qmp_query_firmware_log() then defaults to 1MiB.  Any other
negative number hmp_info_firmware_log() turns into a huge positive
number, which qmp_query_firmware_log() silently limits to 1MiB (but I
recommended not to do that).

Let's use 'o' instead of 'i'.  Enables convenient syntax like "64k".  63
bits.  No risk of sign accidents.

> +        .params     = "[maxsize]",
>          .help       = "show the firmware (ovmf) debug log",
>          .cmd        = hmp_info_firmware_log,
> -        .flags      = "p",

Accident?

>      },
>  
>  SRST
> diff --git a/qapi/machine.json b/qapi/machine.json
> index c96e582afdd6..d0c6d3ede027 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -1857,9 +1857,12 @@
>  #
>  # Find firmware memory log buffer in guest memory, return content.
>  #
> +# @maxsize: limit the amount of logdata returned.

Please spell it @max-size.  We already use that spelling in this file.

"logdata" isn't a word.

The 1MiB limit for @maxsize needs to be documented (if we keep it).

Recommend to spell out that the command returns the tail of the log
buffer when it can't return all of it.

> +#
>  # Since: 10.2
>  ##
>  { 'command': 'query-firmware-log',
> +  'data': { '*maxsize': 'size' },
>    'returns': 'FirmwareLog' }
>  
>  ##



      parent reply	other threads:[~2025-10-14 12:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-13 10:49 [PATCH v4 0/2] hw/uefi: add support for receiving the firmware log via monitor Gerd Hoffmann
2025-10-13 10:49 ` [PATCH v4 1/2] hw/uefi: add "info firmware-log" + "query-firmware-log" monitor commands Gerd Hoffmann
2025-10-14  8:56   ` Daniel P. Berrangé
2025-10-15  6:33     ` Gerd Hoffmann
2025-10-15  7:41       ` Markus Armbruster
2025-10-15  8:08         ` Gerd Hoffmann
2025-10-15  8:17         ` Daniel P. Berrangé
2025-10-14 12:03   ` Markus Armbruster
2025-10-15  6:36     ` Gerd Hoffmann
2025-10-15  7:21       ` Markus Armbruster
2025-10-13 10:49 ` [PATCH v4 2/2] hw/uefi/ovmf-log: add maxsize parameter Gerd Hoffmann
2025-10-14  8:57   ` Daniel P. Berrangé
2025-10-14 12:48   ` Markus Armbruster [this message]

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=874is1odj2.fsf@pond.sub.org \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.