On Tue, Feb 17, 2026 at 3:51 PM Markus Armbruster <[email protected]> wrote: > > Zhang Chen <[email protected]> writes: > > > Extend the 'IOThreadInfo' structure to include attachment metrics. > > This allows users to monitor how many devices are associated with > > a specific IOThread and identify them by their QOM paths. > > > > New fields added to IOThreadInfo: > > - @attached-cnt: An integer representing the number of devices > > currently using this IOThread's AioContext. > > - @attached-dev: A string containing a delimited list ("|") of > > QOM paths for the attached devices. > > > > These fields are also exposed via the Human Monitor Interface (HMP) > > command 'info iothreads' to assist with manual debugging and > > performance tuning. > > > > Example QMP output: > > { > > "id": "iothread0", > > "thread-id": 3134, > > "attached-cnt": 2, > > "attached-dev": "/machine/peripheral/blk1/virtio-backend | > > /machine/peripheral/blk0/virtio-backend", > > ... > > } > > > > Signed-off-by: Zhang Chen <[email protected]> > > [...] > > > diff --git a/qapi/misc.json b/qapi/misc.json > > index 1f5062df2a..ca53638684 100644 > > --- a/qapi/misc.json > > +++ b/qapi/misc.json > > @@ -76,6 +76,19 @@ > > # > > # @thread-id: ID of the underlying host thread > > # > > +# @attached-cnt: The parameter is a counter indicating how many > > +# active devices are currently associated with this iothread > > +# (e.g. virtio-blk). In hotplug scenarios, users can > > +# pre-allocate multiple iothread objects to serve as a persistent > > +# thread pool. When a device is hot-unplugged, the corresponding > > +# IOThread is released but remains available, allowing subsequent > > +# hot-plugged devices to attach to and reuse the existing thread. > > +# (since 11.0) > > +# > > +# @attached-dev: A list of QOM paths for the devices currently > > +# associated with this IOThread, delimited by " | ". > > +# Returns "none" if no devices are attached. (since 11.0) > > QAPI schema design maxim: do not encode structured data as strings. > @attached-devs should be an array of QOM paths instead.
OK, will fix in next version. > > Unless I misunderstand your docs, @attached-cnt is the number of QOM > paths in @attached-dev, i.e. @attached-dev is redundant. If this is the > case, drop it. If it isn't, educate me :) As Stefan's comments, I try to address more specific needs: https://mail.gnu.org/archive/html/qemu-devel/2026-02/msg01892.html > > We generally avoid abbreviations in the QAPI schema: @attached-count, > @attached-devices. > > > +# > > # @poll-max-ns: maximum polling time in ns, 0 means polling is > > # disabled (since 2.9) > > # > > @@ -93,6 +106,8 @@ > > { 'struct': 'IOThreadInfo', > > 'data': {'id': 'str', > > 'thread-id': 'int', > > + 'attached-cnt': 'int', > > + 'attached-dev': 'str', > > 'poll-max-ns': 'int', > > 'poll-grow': 'int', > > 'poll-shrink': 'int', > > @@ -118,6 +133,8 @@ > > # { > > # "id":"iothread0", > > # "thread-id":3134, > > +# "attached-cnt":2, > > +# "attached-dev":/machine/peripheral/blk1/virtio-backend | > > /machine/peripheral/blk0/virtio-backend, > > Once again, the example is syntactically incorrect (the value lacks > double quotes), and once again I recommend to create example I/O by > actually running a test. Getting tired of this, to be frank. Sorry for that again. Will fix in next version. And I tested this series before send the mail like this: (qemu) info iothreads iothread2: thread_id=434428 attached-cnt=0 attached-dev=none poll-max-ns=32768 poll-grow=0 poll-shrink=0 aio-max-batch=0 iothread1: thread_id=434427 attached-cnt=2 attached-dev=/machine/peripheral/blk1/virtio-backend | /machine/peripheral/blk0/virtio-backend poll-max-ns=32768 poll-grow=0 poll-shrink=0 aio-max-batch=0 > > > # "poll-max-ns":32768, > > # "poll-grow":0, > > # "poll-shrink":0, > > @@ -126,6 +143,8 @@ > > # { > > # "id":"iothread1", > > # "thread-id":3135, > > +# "attached-cnt":1, > > +# "attached-dev":/machine/peripheral/blk3/virtio-backend, > > Likewise. Thanks Chen > > > # "poll-max-ns":32768, > > # "poll-grow":0, > > # "poll-shrink":0, >
