On Wed, Feb 11, 2026 at 15:26:49 +0100, Ján Tomko wrote:
> On a Thursday in 2026, Peter Krempa via Devel wrote:
> > From: Peter Krempa <[email protected]>
> >
> > Strictly validating qemu replies and rejecting unknown values can have
> > bad consequences in case qemu adds a new value.
> >
> > Refactor the code parsing 'io-status' field from 'query-block' to be
> > tolerant to new values to avoid failure.
> >
> > Signed-off-by: Peter Krempa <[email protected]>
> > ---
> > src/qemu/qemu_monitor.c | 42 --------------------------------
> > src/qemu/qemu_monitor.h | 3 ---
> > src/qemu/qemu_monitor_json.c | 47 +++++++++++++++++++++++++++++++++---
> > 3 files changed, 43 insertions(+), 49 deletions(-)
[...]
> > @@ -2358,9 +2376,30 @@ qemuMonitorJSONGetBlockInfo(qemuMonitor *mon,
> >
> > /* Missing io-status indicates no error */
> > if ((status = virJSONValueObjectGetString(dev, "io-status"))) {
> > - info.io_status = qemuMonitorBlockIOStatusToError(status);
> > - if (info.io_status < 0)
> > - return -1;
> > + int st = qemuMonitorBlockIOStatusTypeFromString(status);
> > +
> > + if (st < 0) {
> > + VIR_WARN("Unhandled value '%s' of 'io-status' field in
> > 'query-block' reply",
> > + status);
>
> VIR_DEBUG maybe? In case someone calls virDomainGetDiskErrors too often,
> this would get spammy.
Some other places in the monitor code where we process incoming values
also use VIR_WARN. I'll leave it as _WARN for now and I'll have a look
at a possibly more systematic solution which would avoid spam and still
provide discoverability.
Ideally the domain messages API would collect these but plumbing them
out from the monitor code will be hard.
