From: Stefan Hajnoczi <stefanha@redhat.com>
To: Zhang Chen <zhangckid@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
"Dr . David Alan Gilbert" <dave@treblig.org>,
Eric Blake <eblake@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH V7 04/14] blockdev: Update tracking iothread users with holder name
Date: Mon, 11 May 2026 15:05:23 -0400 [thread overview]
Message-ID: <20260511190523.GF536999@fedora> (raw)
In-Reply-To: <20260511140416.28271-5-zhangckid@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3393 bytes --]
On Mon, May 11, 2026 at 10:04:06PM +0800, Zhang Chen wrote:
> Currently, x-blockdev-set-iothread changes the AioContext but does not
> track the IOThread object itself within the block layer. This makes it
> difficult to manage IOThread reference counting (put/get) during
> dynamic context switching.
>
> Introduce an 'iothread' field to BlockDriverState to store the current
> assigned IOThread. Update qmp_x_blockdev_set_iothread to perform
> proper reference counting using iothread_ref/put when moving nodes
> between an IOThread and the main loop.
>
> This ensures 'info iothreads' (holders) accurately reflects the block
> device attachment state after dynamic migrations.
>
> Signed-off-by: Zhang Chen <zhangckid@gmail.com>
> ---
> blockdev.c | 6 +++++-
> include/block/block_int-common.h | 5 +++++
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/blockdev.c b/blockdev.c
> index 6e86c6262f..6e20579187 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -3683,8 +3683,12 @@ void qmp_x_blockdev_set_iothread(const char *node_name, StrOrNull *iothread,
> goto out;
> }
>
> - new_context = iothread_get_aio_context(obj);
> + new_context = iothread_ref_and_get_aio_context(obj, node_name);
> + bs->iothread = obj;
> } else {
> + if (bs->iothread) {
> + iothread_put_aio_context(bs->iothread, node_name);
> + }
> new_context = qemu_get_aio_context();
> }
This command is the wrong place to associate an IOThread with a
BlockDriverState:
1. Do we need to call iothread_put_aio_context() on the current IOThread
when x-blockdev-set-iothread is called with a new IOThread?
2. Is the AioContext leaked when x-blockdev-set-iothread iothread=null
is not called before the BlockDriverState is freed?
Every BlockDriverState would need to get/put the IOThread AioContext in
bdrv_change_aio_context() or related functions.
However, the QEMU block layer has been moving away from having a
per-BlockDriverState AioContext. It is possible to use a
BlockDriverState from any AioContext (including multiple AioContexts at
the same time). I'm in favor of not associating BlockDriverStates with
IOThreads and instead relying on their device owners (e.g. emulated
storage controllers) to be the IOThread holders. That means you could
use iothread->ctx directly or create an
iothread_unsafe_get_aio_context() API to document that this is a
low-level unsafe way of getting the AioContext.
>
> diff --git a/include/block/block_int-common.h b/include/block/block_int-common.h
> index 147c08155f..6edaf53377 100644
> --- a/include/block/block_int-common.h
> +++ b/include/block/block_int-common.h
> @@ -1101,6 +1101,8 @@ typedef struct BdrvBlockStatusCache {
> int64_t data_end;
> } BdrvBlockStatusCache;
>
> +typedef struct IOThread IOThread;
> +
> struct BlockDriverState {
> /*
> * Protected by big QEMU lock or read-only after opening. No special
> @@ -1289,6 +1291,9 @@ struct BlockDriverState {
>
> /* array of write pointers' location of each zone in the zoned device. */
> BlockZoneWps *wps;
> +
> + /* Track the iothread for detach aio context*/
> + IOThread *iothread;
> };
>
> struct BlockBackendRootState {
> --
> 2.49.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-05-11 19:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 14:04 [PATCH V7 00/14] iothread: Support tracking and querying IOThread holders Zhang Chen
2026-05-11 14:04 ` [PATCH V7 01/14] qapi/misc: Fix missed query-iothreads items Zhang Chen
2026-05-11 14:04 ` [PATCH V7 02/14] iothread: introduce iothread_ref/unref to track attached devices Zhang Chen
2026-05-11 18:14 ` Stefan Hajnoczi
2026-05-11 19:15 ` Zhang Chen
2026-05-18 11:58 ` Markus Armbruster
2026-05-18 13:28 ` Zhang Chen
2026-05-18 11:44 ` Markus Armbruster
2026-05-11 14:04 ` [PATCH V7 03/14] iothread: tracking iothread users with holder name Zhang Chen
2026-05-11 18:54 ` Stefan Hajnoczi
2026-05-11 19:06 ` Zhang Chen
2026-05-11 14:04 ` [PATCH V7 04/14] blockdev: Update " Zhang Chen
2026-05-11 19:05 ` Stefan Hajnoczi [this message]
2026-05-11 19:25 ` Zhang Chen
2026-05-11 14:04 ` [PATCH V7 05/14] block/export: track IOThread reference in BlockExport Zhang Chen
2026-05-11 14:04 ` [PATCH V7 06/14] monitor: Update tracking iothread users with holder name Zhang Chen
2026-05-18 11:57 ` Markus Armbruster
2026-05-18 13:47 ` Zhang Chen
2026-05-11 14:04 ` [PATCH V7 07/14] virtio-vq-mapping: track iothread-vq-mapping references using device path Zhang Chen
2026-05-11 14:04 ` [PATCH V7 08/14] virtio: use iothread_get/put_aio_context for thread pinning Zhang Chen
2026-05-11 14:04 ` [PATCH V7 09/14] net/colo: track IOThread references using path-based holder Zhang Chen
2026-05-11 14:04 ` [PATCH V7 10/14] virtio-balloon: Update tracking iothread users with holder name Zhang Chen
2026-05-11 14:04 ` [PATCH V7 11/14] vfio-user/proxy: " Zhang Chen
2026-05-11 14:04 ` [PATCH V7 12/14] xen-block: " Zhang Chen
2026-05-11 14:04 ` [PATCH V7 13/14] qapi: examine IOThread attachment status via query-iothreads Zhang Chen
2026-05-11 14:04 ` [PATCH V7 14/14] iothread: simplify API by merging iothread_get_aio_context variants Zhang Chen
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=20260511190523.GF536999@fedora \
--to=stefanha@redhat.com \
--cc=armbru@redhat.com \
--cc=dave@treblig.org \
--cc=eblake@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=zhangckid@gmail.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.