From: Markus Armbruster <armbru@redhat.com>
To: Peter Krempa <pkrempa@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH v3 1/2] block: Wire up 'flat' mode also for 'query-block'
Date: Wed, 04 Feb 2026 07:11:44 +0100 [thread overview]
Message-ID: <87sebh11i7.fsf@pond.sub.org> (raw)
In-Reply-To: <aYIRgmXsqf09ZfX4@angien.pipo.sk> (Peter Krempa's message of "Tue, 3 Feb 2026 16:17:22 +0100")
Peter Krempa <pkrempa@redhat.com> writes:
> On Tue, Feb 03, 2026 at 13:01:01 +0100, Markus Armbruster wrote:
>> Peter Krempa <pkrempa@redhat.com> writes:
>>
>> > From: Peter Krempa <pkrempa@redhat.com>
>> >
>> > Some time ago (commit facda5443f5a8) I've added 'flat' mode (which
>> > omits 'backing-image' key in reply) to 'query-named-block-nodes' to
>> > minimize the size of the returned JSON for deeper backing chains.
>> >
>> > While 'query-block' behaved slightly better it turns out that in libvirt
>> > we do call 'query-block' to figure out some information about the
>> > block device (e.g. throttling info) but we don't look at the backing
>> > chain itself.
>> >
>> > Wire up 'flat' for 'query-block' so that libvirt can ask for an
>> > abbreviated output. The implementation is much simpler as the internals
>> > are shared with 'query-named-block-nodes'.
>> >
>> > Signed-off-by: Peter Krempa <pkrempa@redhat.com>
>> > Acked-by: Markus Armbruster <armbru@redhat.com>
>>
>> [...]
>>
>> > diff --git a/block/qapi.c b/block/qapi.c
>> > index 27e0ac6a32..3688d0e713 100644
>> > --- a/block/qapi.c
>> > +++ b/block/qapi.c
>>
>> [...]
>>
>> > @@ -698,11 +698,12 @@ bdrv_query_bds_stats(BlockDriverState *bs, bool blk_level)
>> > return s;
>> > }
>> >
>> > -BlockInfoList *qmp_query_block(Error **errp)
>> > +BlockInfoList *qmp_query_block(bool has_flat, bool flat, Error **errp)
>> > {
>> > BlockInfoList *head = NULL, **p_next = &head;
>> > BlockBackend *blk;
>> > Error *local_err = NULL;
>> > + bool return_flat = has_flat && flat;
>>
>> This is fine. Just flat would also be fine: flat implies has_flat.
Verbose version: This is a QMP command handler. The generated
unmarshaler passes has_flat=false, flat=false when @flat is absent, and
has_flat=true, flat=F when @flat is present with value F. Therefore,
flat can only be true when has_flat is also true. Therefore, flat
implies has_flat.
Other code calling QMP command handlers (e.g. HMP commands) must satisfy
this precondition, too.
In fact, any code passing around QAPI-style has_FOO, FOO pairs should
stick to the "when has_FOO is false, FOO is zero bits" convention to
keep things consistent and predictable.
> I've borrowed this from my old patch that added it to
> query-named-block-nodes.
>
> Otherwise I'd have to mark 'has_flat' as unused. Nice side effect would
> be that 'flat' can then be used directly in the call to bdrv_query_info.
We don't -Wunused-variable, so no need to mark anything.
> Alternatively I can move the 'has_flat && flat' expression into the
> arguments of the call to bdrv_query_info to avoid the extra local
> variable.
>
> Whichever you prefer.
Matter of taste, up to you. I just wanted to make sure you know.
>> >
>> > GRAPH_RDLOCK_GUARD_MAINLOOP();
>> >
>> > @@ -714,7 +715,7 @@ BlockInfoList *qmp_query_block(Error **errp)
>> > }
>> >
>> > info = g_malloc0(sizeof(*info));
>> > - bdrv_query_info(blk, &info->value, &local_err);
>> > + bdrv_query_info(blk, return_flat, &info->value, &local_err);
>> > if (local_err) {
>> > error_propagate(errp, local_err);
>> > g_free(info);
>> > diff --git a/qapi/block-core.json b/qapi/block-core.json
>> > index b82af74256..a701f6bbee 100644
>> > --- a/qapi/block-core.json
>> > +++ b/qapi/block-core.json
>> > @@ -855,6 +855,10 @@
>> > #
>> > # Get a list of `BlockInfo` for all virtual block devices.
>> > #
>> > +# @flat: Omit nested data about the backing image (ie. the contents at
>> > +# 'inserted.image.backing-image' are trimmed).
>> > +# Default is false (Since 11.0)
>> > +#
>>
>> s/ie./i.e./
>>
>> Remind me: true suppresses member inserted.image.backing-image, i.e. it
>> is absent then. Correct?
>
> Yes the 'backing-image' key is completely missing when @flat is true.
Okay. What about this:
# @flat: Omit nested data about the backing image, i.e. `BlockInfo`
# member 'inserted.image.backing-image' will be absent. Default is
# false. (Since 11.0)
next prev parent reply other threads:[~2026-02-04 6:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 8:49 [PATCH v3 0/2] block: Wire up 'flat' mode also for 'query-block' Peter Krempa
2026-02-03 8:49 ` [PATCH v3 1/2] " Peter Krempa
2026-02-03 12:01 ` Markus Armbruster
2026-02-03 15:17 ` Peter Krempa
2026-02-04 6:11 ` Markus Armbruster [this message]
2026-02-04 13:13 ` Peter Krempa
2026-02-03 8:49 ` [PATCH v3 2/2] hmp_nbd_server_start: Don't ask for backing image data Peter Krempa
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=87sebh11i7.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=pkrempa@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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.