Re: [PATCH v5 00/35] monitor: turn QMP and HMP into QOM objects

[Markus Armbruster <armbru@redhat.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?

[...]