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? [...]