On Wed, Jul 01, 2026 at 09:52:44AM +0200, Markus Armbruster wrote: > Daniel P. Berrangé <[email protected]> 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 :|
