Conceptually -object and object_add/object_del should be sufficient
for essentially all QEMU configuration....if only we ported all our
internal custom backends/devices/etc to QOM. That is of course a big
job which is why it hasn't happened.

This series started with the premise that the monitor is one of the
easier areas to convert since we have no more than three classes,
a common base, and QMP and HMP subclasses[1]. So why not give it a
go and thus unlock the ability to dynamically create/delete monitors
in QMP/HMP.

This series does the conversion in a great many small steps to better
understand the implications at each stage.

The high level outcome of this series is

 * HMP and QMP monitors are QOM objects, 'monitor-hmp' and
   'monitor-qmp' respectively

 * Both can be cold plugged and hot plugged. QMP only, can
   also be hot unplugged.

 * '-mon' is obsolete, deprecated and replaced by '-object',
   but -monitor, -qmp and kept  as high level syntax sugar

 * QMP gains a concept of "close-action" which makes it
   possible to mark a monitor for auto-delete.

The monitor hot-unplug code and the qtest and functional testing
code is heavily derived from a series sent by Christian Brauner
which proposed new monitor_add/monitor_del commands:

  https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html

I left Christian's authorship & SoB on the patches which were
derived from his code, though the code has been refactored quite
a bit in places, so bugs are quite possibly my own.

Note that Christian's series allowed the use of "monitor_del"
commands against the current monitor session. ie a client could
delete the very monitor it was using. This is an awkward concept
as it needs special casing to delay the deletion to happen in
the background, such that that the QMP response to 'monitor_del'
could still be sent back. This also left the chardev was orphaned
as there's no way to run 'chardev_dev' in that usage pattern.

To provide an alternative mechanism to address the same use case,
this series introduces the 'close-action' concept mentioned above,
that allows hotplugging a monitor to service a specific task,
with the monitor being purged when the script closes its connection.
This avoids the special casing that an explicit "self deletion"
paradigm required.

While supporting hotplug of HMP was trivial, I didn't do any work
to think about hotunplug of HMP, since IMHO it is of limited value
given HMP's typical use cases.

[1] ~~~ we did all this not because it was easy,
        but because we thought it would be easy ~~~

Changed in v5:

 - Address another race when looking up monitor by ID
 - Refer to "line editting" when talking about HMP
   readline feature
 - Misc typos
 - Fix mis-placed setting of 'delete_pending'
 - Add test case to validate reconnecting to QMP

Changed in v4:

 - Hold reference into BH to avoid race with auto-delete

Changed in v3:

 - Removed unused 'dead' struct field
 - Make use of 'setup_pending' struct field across BH
 - Add missing free of chardev_id
 - Add missnig ERRP_GUARD in monitor_new_qmp
 - Misc docs typos / rephrasing
 - Moved docs patch to the end
 - Fixed docs about the default QOM ID naming for legacy
   monitor syntax
 - Fixed random sleep time calculation in tests

Christian Brauner (6):
  monitor: convert from oneshot BH to persistent BH
  monitor: reject attempts to delete the current monitor
  monitor: protect qemu_chr_fe_accept_input with monitor lock
  monitor: implement support for deleting QMP objects
  tests/qtest: add tests for dynamic monitor add/remove
  tests/functional: add e2e test for dynamic QMP monitor hotplug

Daniel P. Berrangé (29):
  qom: replace 'can_be_deleted' with 'prepare_delete'
  monitor: replace 'common' with 'parent_obj' in MonitorHMP
  monitor: replace 'common' with 'parent_obj' in MonitorQMP
  monitor: rename monitor_init* to monitor_new*
  monitor: minimal conversion of monitors to QOM
  monitor: add 'chardev' property to Monitor base class
  monitor: add 'readline' property to HMP Monitor class
  monitor: add 'pretty' property to QMP Monitor class
  monitor: remove 'skip_flush' field
  monitor: move monitor_data_(init|destroy) into QOM init/finalize
  monitor: use class methods for monitor_vprintf
  monitor: use class methods for monitor_qapi_event_emit
  monitor: use class methods for monitor_accept_input
  monitor: use class method for I/O thread request
  monitor: use dynamic cast in monitor_qmp_requests_pop_any_with_lock
  util: use dynamic cast in error vreport
  monitor: drop unused monitor_cur_is_qmp
  monitor: use dynamic cast in QMP commands
  monitor: use dynamic cast in monitor_is_hmp_non_interactive
  monitor: drop unused monitor_is_qmp method
  monitor: eliminate monitor_is_hmp_non_interactive method
  monitor: implement "user creatable" interface for adding monitors
  tests/functional: add a stress test for monitor hot unplug
  qom: add method for getting the "id" of a QOM object
  qom: add trace events for user creatable create/delete APIs
  monitor: add support for auto-deleting monitors upon close
  tests: switch from -mon to -object monitor-qmp
  qemu-options: document new monitor-hmp and monitor-qmp objects
  docs: mark '-mon' as deprecated in favour of -object

 MAINTAINERS                                   |   1 +
 backends/cryptodev.c                          |  10 +-
 backends/hostmem.c                            |   5 +-
 backends/iommufd.c                            |  10 +-
 block/throttle-groups.c                       |  10 +-
 chardev/char.c                                |   3 +-
 docs/about/deprecated.rst                     |  10 +
 docs/devel/writing-monitor-commands.rst       |   4 +-
 docs/system/arm/xenpvh.rst                    |   4 +-
 docs/system/i386/xen.rst                      |   3 +-
 docs/system/i386/xenpvh.rst                   |   4 +-
 event-loop-base.c                             |   8 +-
 gdbstub/system.c                              |   4 +-
 include/monitor/monitor.h                     |  23 +-
 include/qom/object.h                          |  10 +
 include/qom/object_interfaces.h               |  26 +-
 include/system/event-loop-base.h              |   2 +-
 migration/migration-hmp-cmds.c                |   5 +-
 monitor/hmp-cmds.c                            |   7 +-
 monitor/hmp.c                                 | 181 ++++++++--
 monitor/monitor-internal.h                    |  73 ++--
 monitor/monitor.c                             | 262 +++++++-------
 monitor/qmp-cmds-control.c                    |  12 +-
 monitor/qmp-cmds.c                            |  14 +-
 monitor/qmp.c                                 | 319 +++++++++++++++---
 net/can/can_core.c                            |   5 +-
 python/qemu/machine/machine.py                |   4 +-
 qapi/qom.json                                 |  62 ++++
 qemu-options.hx                               |  56 ++-
 qom/object.c                                  |  17 +
 qom/object_interfaces.c                       |  20 +-
 qom/trace-events                              |   5 +
 storage-daemon/qemu-storage-daemon.c          |   2 +-
 stubs/monitor-core.c                          |   5 -
 stubs/monitor-internal.c                      |   3 +-
 system/vl.c                                   |  12 +-
 tests/functional/generic/meson.build          |   1 +
 .../generic/test_monitor_hotplug.py           | 305 +++++++++++++++++
 tests/qemu-iotests/245                        |   4 +-
 tests/qtest/libqtest.c                        |   2 +-
 tests/qtest/qmp-test.c                        | 174 ++++++++++
 tests/unit/test-util-sockets.c                |   1 -
 tools/qemu-vnc/stubs.c                        |   5 -
 ui/ui-hmp-cmds.c                              |   2 +-
 util/error-report.c                           |  13 +-
 util/main-loop.c                              |   5 +-
 46 files changed, 1386 insertions(+), 327 deletions(-)
 create mode 100755 tests/functional/generic/test_monitor_hotplug.py

-- 
2.54.0

Markus,

This series is fully reviewed now by multiple people.

Do you have any plans to do reviews and/or queue this as maintainer,
or will you ack it for me to send a pull request.

I would like to get this merged before soft freeze which is fast
approaching.

On Wed, Jun 24, 2026 at 06:37:16PM +0100, Daniel P. Berrangé wrote:
> Conceptually -object and object_add/object_del should be sufficient
> for essentially all QEMU configuration....if only we ported all our
> internal custom backends/devices/etc to QOM. That is of course a big
> job which is why it hasn't happened.
> 
> This series started with the premise that the monitor is one of the
> easier areas to convert since we have no more than three classes,
> a common base, and QMP and HMP subclasses[1]. So why not give it a
> go and thus unlock the ability to dynamically create/delete monitors
> in QMP/HMP.
> 
> This series does the conversion in a great many small steps to better
> understand the implications at each stage.
> 
> The high level outcome of this series is
> 
>  * HMP and QMP monitors are QOM objects, 'monitor-hmp' and
>    'monitor-qmp' respectively
> 
>  * Both can be cold plugged and hot plugged. QMP only, can
>    also be hot unplugged.
> 
>  * '-mon' is obsolete, deprecated and replaced by '-object',
>    but -monitor, -qmp and kept  as high level syntax sugar
> 
>  * QMP gains a concept of "close-action" which makes it
>    possible to mark a monitor for auto-delete.
> 
> The monitor hot-unplug code and the qtest and functional testing
> code is heavily derived from a series sent by Christian Brauner
> which proposed new monitor_add/monitor_del commands:
> 
>   https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html
> 
> I left Christian's authorship & SoB on the patches which were
> derived from his code, though the code has been refactored quite
> a bit in places, so bugs are quite possibly my own.
> 
> Note that Christian's series allowed the use of "monitor_del"
> commands against the current monitor session. ie a client could
> delete the very monitor it was using. This is an awkward concept
> as it needs special casing to delay the deletion to happen in
> the background, such that that the QMP response to 'monitor_del'
> could still be sent back. This also left the chardev was orphaned
> as there's no way to run 'chardev_dev' in that usage pattern.
> 
> To provide an alternative mechanism to address the same use case,
> this series introduces the 'close-action' concept mentioned above,
> that allows hotplugging a monitor to service a specific task,
> with the monitor being purged when the script closes its connection.
> This avoids the special casing that an explicit "self deletion"
> paradigm required.
> 
> While supporting hotplug of HMP was trivial, I didn't do any work
> to think about hotunplug of HMP, since IMHO it is of limited value
> given HMP's typical use cases.
> 
> [1] ~~~ we did all this not because it was easy,
>         but because we thought it would be easy ~~~
> 
> Changed in v5:
> 
>  - Address another race when looking up monitor by ID
>  - Refer to "line editting" when talking about HMP
>    readline feature
>  - Misc typos
>  - Fix mis-placed setting of 'delete_pending'
>  - Add test case to validate reconnecting to QMP
> 
> Changed in v4:
> 
>  - Hold reference into BH to avoid race with auto-delete
> 
> Changed in v3:
> 
>  - Removed unused 'dead' struct field
>  - Make use of 'setup_pending' struct field across BH
>  - Add missing free of chardev_id
>  - Add missnig ERRP_GUARD in monitor_new_qmp
>  - Misc docs typos / rephrasing
>  - Moved docs patch to the end
>  - Fixed docs about the default QOM ID naming for legacy
>    monitor syntax
>  - Fixed random sleep time calculation in tests
> 
> Christian Brauner (6):
>   monitor: convert from oneshot BH to persistent BH
>   monitor: reject attempts to delete the current monitor
>   monitor: protect qemu_chr_fe_accept_input with monitor lock
>   monitor: implement support for deleting QMP objects
>   tests/qtest: add tests for dynamic monitor add/remove
>   tests/functional: add e2e test for dynamic QMP monitor hotplug
> 
> Daniel P. Berrangé (29):
>   qom: replace 'can_be_deleted' with 'prepare_delete'
>   monitor: replace 'common' with 'parent_obj' in MonitorHMP
>   monitor: replace 'common' with 'parent_obj' in MonitorQMP
>   monitor: rename monitor_init* to monitor_new*
>   monitor: minimal conversion of monitors to QOM
>   monitor: add 'chardev' property to Monitor base class
>   monitor: add 'readline' property to HMP Monitor class
>   monitor: add 'pretty' property to QMP Monitor class
>   monitor: remove 'skip_flush' field
>   monitor: move monitor_data_(init|destroy) into QOM init/finalize
>   monitor: use class methods for monitor_vprintf
>   monitor: use class methods for monitor_qapi_event_emit
>   monitor: use class methods for monitor_accept_input
>   monitor: use class method for I/O thread request
>   monitor: use dynamic cast in monitor_qmp_requests_pop_any_with_lock
>   util: use dynamic cast in error vreport
>   monitor: drop unused monitor_cur_is_qmp
>   monitor: use dynamic cast in QMP commands
>   monitor: use dynamic cast in monitor_is_hmp_non_interactive
>   monitor: drop unused monitor_is_qmp method
>   monitor: eliminate monitor_is_hmp_non_interactive method
>   monitor: implement "user creatable" interface for adding monitors
>   tests/functional: add a stress test for monitor hot unplug
>   qom: add method for getting the "id" of a QOM object
>   qom: add trace events for user creatable create/delete APIs
>   monitor: add support for auto-deleting monitors upon close
>   tests: switch from -mon to -object monitor-qmp
>   qemu-options: document new monitor-hmp and monitor-qmp objects
>   docs: mark '-mon' as deprecated in favour of -object
> 
>  MAINTAINERS                                   |   1 +
>  backends/cryptodev.c                          |  10 +-
>  backends/hostmem.c                            |   5 +-
>  backends/iommufd.c                            |  10 +-
>  block/throttle-groups.c                       |  10 +-
>  chardev/char.c                                |   3 +-
>  docs/about/deprecated.rst                     |  10 +
>  docs/devel/writing-monitor-commands.rst       |   4 +-
>  docs/system/arm/xenpvh.rst                    |   4 +-
>  docs/system/i386/xen.rst                      |   3 +-
>  docs/system/i386/xenpvh.rst                   |   4 +-
>  event-loop-base.c                             |   8 +-
>  gdbstub/system.c                              |   4 +-
>  include/monitor/monitor.h                     |  23 +-
>  include/qom/object.h                          |  10 +
>  include/qom/object_interfaces.h               |  26 +-
>  include/system/event-loop-base.h              |   2 +-
>  migration/migration-hmp-cmds.c                |   5 +-
>  monitor/hmp-cmds.c                            |   7 +-
>  monitor/hmp.c                                 | 181 ++++++++--
>  monitor/monitor-internal.h                    |  73 ++--
>  monitor/monitor.c                             | 262 +++++++-------
>  monitor/qmp-cmds-control.c                    |  12 +-
>  monitor/qmp-cmds.c                            |  14 +-
>  monitor/qmp.c                                 | 319 +++++++++++++++---
>  net/can/can_core.c                            |   5 +-
>  python/qemu/machine/machine.py                |   4 +-
>  qapi/qom.json                                 |  62 ++++
>  qemu-options.hx                               |  56 ++-
>  qom/object.c                                  |  17 +
>  qom/object_interfaces.c                       |  20 +-
>  qom/trace-events                              |   5 +
>  storage-daemon/qemu-storage-daemon.c          |   2 +-
>  stubs/monitor-core.c                          |   5 -
>  stubs/monitor-internal.c                      |   3 +-
>  system/vl.c                                   |  12 +-
>  tests/functional/generic/meson.build          |   1 +
>  .../generic/test_monitor_hotplug.py           | 305 +++++++++++++++++
>  tests/qemu-iotests/245                        |   4 +-
>  tests/qtest/libqtest.c                        |   2 +-
>  tests/qtest/qmp-test.c                        | 174 ++++++++++
>  tests/unit/test-util-sockets.c                |   1 -
>  tools/qemu-vnc/stubs.c                        |   5 -
>  ui/ui-hmp-cmds.c                              |   2 +-
>  util/error-report.c                           |  13 +-
>  util/main-loop.c                              |   5 +-
>  46 files changed, 1386 insertions(+), 327 deletions(-)
>  create mode 100755 tests/functional/generic/test_monitor_hotplug.py
> 
> -- 
> 2.54.0
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Daniel P. Berrangé <berrange@redhat.com> writes:

> Markus,
>
> This series is fully reviewed now by multiple people.
>
> Do you have any plans to do reviews and/or queue this as maintainer,
> or will you ack it for me to send a pull request.
>
> I would like to get this merged before soft freeze which is fast
> approaching.

Soft freeze is in a week, and the heat wave left me seriously
sleep-deprived.

I'd like to give your interface changes an eye-over.  I probably won't
be able to do more in time for the soft freeze.

On Mon, Jun 29, 2026 at 01:01:13PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > Markus,
> >
> > This series is fully reviewed now by multiple people.
> >
> > Do you have any plans to do reviews and/or queue this as maintainer,
> > or will you ack it for me to send a pull request.
> >
> > I would like to get this merged before soft freeze which is fast
> > approaching.
> 
> Soft freeze is in a week, and the heat wave left me seriously
> sleep-deprived.
> 
> I'd like to give your interface changes an eye-over.  I probably won't
> be able to do more in time for the soft freeze.

In terms of interfaces...

Patch 22 is where we define the QAPI for the new user-creatable QOM
objects for HMP/QMP, to enable use with -object / object-add.

Patch 32 is where we define the QAPI for the new auto-delete-on-close
concept for the monitor.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Mon, Jun 29, 2026 at 01:01:13PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > Markus,
>> >
>> > This series is fully reviewed now by multiple people.
>> >
>> > Do you have any plans to do reviews and/or queue this as maintainer,
>> > or will you ack it for me to send a pull request.
>> >
>> > I would like to get this merged before soft freeze which is fast
>> > approaching.
>> 
>> Soft freeze is in a week, and the heat wave left me seriously
>> sleep-deprived.
>> 
>> I'd like to give your interface changes an eye-over.  I probably won't
>> be able to do more in time for the soft freeze.
>
> In terms of interfaces...
>
> Patch 22 is where we define the QAPI for the new user-creatable QOM
> objects for HMP/QMP, to enable use with -object / object-add.
>
> Patch 32 is where we define the QAPI for the new auto-delete-on-close
> concept for the monitor.

Thanks!

I'll try to also look at PATCH 34 and 35.

Daniel P. Berrangé <berrange@redhat.com> writes:

> Conceptually -object and object_add/object_del should be sufficient
> for essentially all QEMU configuration....if only we ported all our
> internal custom backends/devices/etc to QOM. That is of course a big
> job which is why it hasn't happened.
>
> This series started with the premise that the monitor is one of the
> easier areas to convert since we have no more than three classes,
> a common base, and QMP and HMP subclasses[1]. So why not give it a
> go and thus unlock the ability to dynamically create/delete monitors
> in QMP/HMP.
>
> This series does the conversion in a great many small steps to better
> understand the implications at each stage.
>
> The high level outcome of this series is
>
>  * HMP and QMP monitors are QOM objects, 'monitor-hmp' and
>    'monitor-qmp' respectively
>
>  * Both can be cold plugged and hot plugged. QMP only, can
>    also be hot unplugged.
>
>  * '-mon' is obsolete, deprecated and replaced by '-object',
>    but -monitor, -qmp and kept  as high level syntax sugar

Possible additional work: change monitor_parse() to build a
MonitorOptions instead of a QemuOpts, so it call monitor_new() directly
instead of via monitor_new_opts().  Observation, not a demand.

>
>  * QMP gains a concept of "close-action" which makes it
>    possible to mark a monitor for auto-delete.

I'm not quite convinced this is warranted.  I'd like to hear more about
use cases.

Is libvirt going to make use of it?

> The monitor hot-unplug code and the qtest and functional testing
> code is heavily derived from a series sent by Christian Brauner
> which proposed new monitor_add/monitor_del commands:
>
>   https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html
>
> I left Christian's authorship & SoB on the patches which were
> derived from his code, though the code has been refactored quite
> a bit in places, so bugs are quite possibly my own.
>
> Note that Christian's series allowed the use of "monitor_del"
> commands against the current monitor session. ie a client could
> delete the very monitor it was using. This is an awkward concept
> as it needs special casing to delay the deletion to happen in
> the background, such that that the QMP response to 'monitor_del'
> could still be sent back. This also left the chardev was orphaned
> as there's no way to run 'chardev_dev' in that usage pattern.
>
> To provide an alternative mechanism to address the same use case,
> this series introduces the 'close-action' concept mentioned above,
> that allows hotplugging a monitor to service a specific task,
> with the monitor being purged when the script closes its connection.
> This avoids the special casing that an explicit "self deletion"
> paradigm required.
>
> While supporting hotplug of HMP was trivial, I didn't do any work
> to think about hotunplug of HMP, since IMHO it is of limited value
> given HMP's typical use cases.
>
> [1] ~~~ we did all this not because it was easy,
>         but because we thought it would be easy ~~~

Heh!

Fully addressing all review comments before the soft freeze may or may
not be possible.  Perhaps punting sufficiently harmless changes to a
post-freeze fixup series could help.  Use your judgement.

We could also leave the close-action feature for the next development
cycle.

On Wed, Jul 01, 2026 at 09:52:44AM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > Conceptually -object and object_add/object_del should be sufficient
> > for essentially all QEMU configuration....if only we ported all our
> > internal custom backends/devices/etc to QOM. That is of course a big
> > job which is why it hasn't happened.
> >
> > This series started with the premise that the monitor is one of the
> > easier areas to convert since we have no more than three classes,
> > a common base, and QMP and HMP subclasses[1]. So why not give it a
> > go and thus unlock the ability to dynamically create/delete monitors
> > in QMP/HMP.
> >
> > This series does the conversion in a great many small steps to better
> > understand the implications at each stage.
> >
> > The high level outcome of this series is
> >
> >  * HMP and QMP monitors are QOM objects, 'monitor-hmp' and
> >    'monitor-qmp' respectively
> >
> >  * Both can be cold plugged and hot plugged. QMP only, can
> >    also be hot unplugged.
> >
> >  * '-mon' is obsolete, deprecated and replaced by '-object',
> >    but -monitor, -qmp and kept  as high level syntax sugar
> 
> Possible additional work: change monitor_parse() to build a
> MonitorOptions instead of a QemuOpts, so it call monitor_new() directly
> instead of via monitor_new_opts().  Observation, not a demand.
> 
> >
> >  * QMP gains a concept of "close-action" which makes it
> >    possible to mark a monitor for auto-delete.
> 
> I'm not quite convinced this is warranted.  I'd like to hear more about
> use cases.

Replied about that inline to the patch. IMHO without this facility
the series does not fully address the needs of systemd that motivated
the original patches:

  https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html

> Is libvirt going to make use of it?

This wasn't motivated by libvirt's needs, but indeed it could be
useful for libvirt. Currently if apps want to access QMP, they
need to use libvirt's QMP passthrough, which means they need
special client code to talk to libvirt APIs.

With this libvirt could dynamically add a monitor, with auto
close, open it and pass the open FD back to the client app.
libvirt would not need to watch for when the client app is
gone as dropping the FD would cleanup the monitor.


> Fully addressing all review comments before the soft freeze may or may
> not be possible.  Perhaps punting sufficiently harmless changes to a
> post-freeze fixup series could help.  Use your judgement.
> 
> We could also leave the close-action feature for the next development
> cycle.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Jul 01, 2026 at 09:52:44AM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > Conceptually -object and object_add/object_del should be sufficient
>> > for essentially all QEMU configuration....if only we ported all our
>> > internal custom backends/devices/etc to QOM. That is of course a big
>> > job which is why it hasn't happened.
>> >
>> > This series started with the premise that the monitor is one of the
>> > easier areas to convert since we have no more than three classes,
>> > a common base, and QMP and HMP subclasses[1]. So why not give it a
>> > go and thus unlock the ability to dynamically create/delete monitors
>> > in QMP/HMP.
>> >
>> > This series does the conversion in a great many small steps to better
>> > understand the implications at each stage.
>> >
>> > The high level outcome of this series is
>> >
>> >  * HMP and QMP monitors are QOM objects, 'monitor-hmp' and
>> >    'monitor-qmp' respectively
>> >
>> >  * Both can be cold plugged and hot plugged. QMP only, can
>> >    also be hot unplugged.
>> >
>> >  * '-mon' is obsolete, deprecated and replaced by '-object',
>> >    but -monitor, -qmp and kept  as high level syntax sugar
>> 
>> Possible additional work: change monitor_parse() to build a
>> MonitorOptions instead of a QemuOpts, so it call monitor_new() directly
>> instead of via monitor_new_opts().  Observation, not a demand.
>> 
>> >
>> >  * QMP gains a concept of "close-action" which makes it
>> >    possible to mark a monitor for auto-delete.
>> 
>> I'm not quite convinced this is warranted.  I'd like to hear more about
>> use cases.
>
> Replied about that inline to the patch. IMHO without this facility
> the series does not fully address the needs of systemd that motivated
> the original patches:
>
>   https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html
>
>> Is libvirt going to make use of it?
>
> This wasn't motivated by libvirt's needs, but indeed it could be
> useful for libvirt. Currently if apps want to access QMP, they
> need to use libvirt's QMP passthrough, which means they need
> special client code to talk to libvirt APIs.
>
> With this libvirt could dynamically add a monitor, with auto
> close, open it and pass the open FD back to the client app.
> libvirt would not need to watch for when the client app is
> gone as dropping the FD would cleanup the monitor.

Alright, that's fair.  The management application doesn't spawn
something that wants a dedicated monitor, it makes one for a client.

Would this fit into a commit message somewhere?

[...]

On Wed, Jul 01, 2026 at 03:41:26PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Wed, Jul 01, 2026 at 09:52:44AM +0200, Markus Armbruster wrote:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> 
> >> > Conceptually -object and object_add/object_del should be sufficient
> >> > for essentially all QEMU configuration....if only we ported all our
> >> > internal custom backends/devices/etc to QOM. That is of course a big
> >> > job which is why it hasn't happened.
> >> >
> >> > This series started with the premise that the monitor is one of the
> >> > easier areas to convert since we have no more than three classes,
> >> > a common base, and QMP and HMP subclasses[1]. So why not give it a
> >> > go and thus unlock the ability to dynamically create/delete monitors
> >> > in QMP/HMP.
> >> >
> >> > This series does the conversion in a great many small steps to better
> >> > understand the implications at each stage.
> >> >
> >> > The high level outcome of this series is
> >> >
> >> >  * HMP and QMP monitors are QOM objects, 'monitor-hmp' and
> >> >    'monitor-qmp' respectively
> >> >
> >> >  * Both can be cold plugged and hot plugged. QMP only, can
> >> >    also be hot unplugged.
> >> >
> >> >  * '-mon' is obsolete, deprecated and replaced by '-object',
> >> >    but -monitor, -qmp and kept  as high level syntax sugar
> >> 
> >> Possible additional work: change monitor_parse() to build a
> >> MonitorOptions instead of a QemuOpts, so it call monitor_new() directly
> >> instead of via monitor_new_opts().  Observation, not a demand.
> >> 
> >> >
> >> >  * QMP gains a concept of "close-action" which makes it
> >> >    possible to mark a monitor for auto-delete.
> >> 
> >> I'm not quite convinced this is warranted.  I'd like to hear more about
> >> use cases.
> >
> > Replied about that inline to the patch. IMHO without this facility
> > the series does not fully address the needs of systemd that motivated
> > the original patches:
> >
> >   https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html
> >
> >> Is libvirt going to make use of it?
> >
> > This wasn't motivated by libvirt's needs, but indeed it could be
> > useful for libvirt. Currently if apps want to access QMP, they
> > need to use libvirt's QMP passthrough, which means they need
> > special client code to talk to libvirt APIs.
> >
> > With this libvirt could dynamically add a monitor, with auto
> > close, open it and pass the open FD back to the client app.
> > libvirt would not need to watch for when the client app is
> > gone as dropping the FD would cleanup the monitor.
> 
> Alright, that's fair.  The management application doesn't spawn
> something that wants a dedicated monitor, it makes one for a client.
> 
> Would this fit into a commit message somewhere?

Sure, it fits in the commit message for the auto-delete patch.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|