On Tue, Jun 23, 2026 at 03:54:54PM +0400, Marc-André Lureau wrote: > Hi > > On Tue, Jun 23, 2026 at 3:53 PM Daniel P. Berrangé <[email protected]> > wrote: > > > > On Tue, Jun 23, 2026 at 12:38:10PM +0100, Daniel P. Berrangé wrote: > > > On Tue, Jun 23, 2026 at 01:03:46PM +0200, Peter Krempa wrote: > > > > On Tue, Jun 23, 2026 at 10:55:16 +0100, Daniel P. Berrangé via Devel > > > > 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 > > > > > > > > I was giving this a spin by implementing libvirt support for it. The > > > > basic usage seems to work well but I've encoutered a regression in > > > > behaviour which happens both when the QMP monitor is instantiated using > > > > the new syntax but also the old one > > > > ( -mon chardev=charmonitor,id=monitor,mode=control) > > > > > > > > When libvirt wants to re-connect to a qemu running with these patches it > > > > re-issues a 'qmp_capabilities' command after connecting. > > > > > > > > With these patches qemu does not respond to that command even when the > > > > old syntax is used. This makes libvirt stuck when re-connecting to VMs. > > > > > > Oh that's odd, thanks for the warning. I'll investigate this. > > > > /face-palm - a misplaced a line in the auto-delete code, and did not > > have test coverage of re-opening a monitor. Try testing libvirt with > > this additional change on top > > > > diff --git a/monitor/qmp.c b/monitor/qmp.c > > index f6b7fe65bb..10d651ca5c 100644 > > --- a/monitor/qmp.c > > +++ b/monitor/qmp.c > > @@ -613,7 +613,6 @@ static void monitor_qmp_event(void *opaque, > > QEMUChrEvent event) > > qobject_unref(data); > > break; > > case CHR_EVENT_CLOSED: > > - mon->delete_pending = true; > > /* > > * Note: this is only useful when the output of the chardev > > * backend is still open. For example, when the backend is > > @@ -629,6 +628,7 @@ static void monitor_qmp_event(void *opaque, > > QEMUChrEvent event) > > case MONITOR_QMP_CLOSE_ACTION_NONE: > > break; /* nada */ > > case MONITOR_QMP_CLOSE_ACTION_DELETE: > > + mon->delete_pending = true; > > /* > > * Do NOT run in the AIO context associated with the > > * monitor. We need to run in the default AIO context > > > > > > Good, I just asked the same in my review :) > > btw, you didn't collect my r-b from v3.
Oh sorry, I will get those. 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 :|
