On Wed, Oct 08, 2025 at 08:32:39AM +0200, Markus Armbruster wrote: > Gerd Hoffmann <[email protected]> writes: > > > 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 <[email protected]> > > [...] > > > diff --git a/tests/qtest/qmp-cmd-test.c b/tests/qtest/qmp-cmd-test.c > > index cf718761861d..ffdb7e979e0f 100644 > > --- a/tests/qtest/qmp-cmd-test.c > > +++ b/tests/qtest/qmp-cmd-test.c > > @@ -52,6 +52,8 @@ static int query_error_class(const char *cmd) > > /* Only valid with accel=tcg */ > > { "x-query-jit", ERROR_CLASS_GENERIC_ERROR }, > > { "xen-event-list", ERROR_CLASS_GENERIC_ERROR }, > > + /* requires firmware with memory buffer logging support */ > > + { "query-ovmf-log", ERROR_CLASS_GENERIC_ERROR }, > > { NULL, -1 } > > }; > > int i; > > Makes sense. > > > diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx > > index 6142f60e7b16..eca0614903d1 100644 > > --- a/hmp-commands-info.hx > > +++ b/hmp-commands-info.hx > > @@ -977,3 +977,16 @@ SRST > > ``info cryptodev`` > > Show the crypto devices. > > ERST > > + > > + { > > + .name = "ovmf-log", > > + .args_type = "", > > + .params = "", > > + .help = "show the ovmf debug log", > > + .cmd_info_hrt = qmp_query_ovmf_log, > > + }, > > + > > +SRST > > + ``info ovmf-log`` > > + Show the ovmf debug log. > > +ERST > > diff --git a/hw/uefi/meson.build b/hw/uefi/meson.build > > index 91eb95f89e6d..c8f38dfae247 100644 > > --- a/hw/uefi/meson.build > > +++ b/hw/uefi/meson.build > > @@ -1,4 +1,4 @@ > > -system_ss.add(files('hardware-info.c')) > > +system_ss.add(files('hardware-info.c', 'ovmf-log.c')) > > > > uefi_vars_ss = ss.source_set() > > if (config_all_devices.has_key('CONFIG_UEFI_VARS')) > > diff --git a/qapi/machine.json b/qapi/machine.json > > index 038eab281c78..329034035029 100644 > > --- a/qapi/machine.json > > +++ b/qapi/machine.json > > @@ -1839,6 +1839,16 @@ > > 'returns': 'HumanReadableText', > > 'features': [ 'unstable' ]} > > > > +## > > +# @query-ovmf-log: > > +# > > +# Find firmware memory log buffer in guest memory, return content. > > +# > > +# Since: 10.2 > > +## > > +{ 'command': 'query-ovmf-log', > > + 'returns': 'HumanReadableText' } > > All other commands returning HumanReadableText are unstable. Does this > one need to be stable? If yes, why?
The main reason why all the others are 'unstable' is that I did a "blind" conversion of "info XXXX" to "x-query-XXXX", with no consideration for the data design. They are all returning structured data munged into an opaque string targetted at humans, not machines. For this log command the data is inherantly a string to begin with, so the general problem data design doesn't apply here. This command is suitable for consumption both by machines and humans. Overall I think it is reasonable to consider this new command stable. Maybe this means we should return 'str' instead of 'HumanReadableText' to distinguish it ? 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 :|
