Daniel P. Berrangé <berrange@redhat.com> writes:
On Wed, Jul 01, 2026 at 08:32:06AM +0200, Markus Armbruster wrote:
marcandre.lureau@redhat.com writes:
The default monitor is usually a long lived object that will exist for the entire lifetime of the VM. A monitor can only service a single client at a time though, and so it might be desirable to hotplug additional monitors at runtime for specific tasks. If doing that, however, there is a need to remove the monitor when it is no longer needed.
Whatever adds the additional monitor can also delete it. The fact that you propose other means suggests you believe this would be cumbersome in practice. Why?
The use is is that someone/something wants to spawn a script that does some job with the QEMU monitor. The thing that spawns the script adds the new monitor and launches the script. Having auto-delete means that you do not need to then keep track of that script to perform cleanup of the dynamically added monitor. It gives you "do the right thing" behaviour automatically when the script exits, closing its monitor connection.
The initial series proposed by Christian supported the ability to run "object-del' on the monitor itself - a "self delete" essentially. That is very awkward from the code POV, as it required special case hanlding to ensure the QMP response to the delete action got sent on the socket before the delete action took place. It also made it impossible to then delete the character device.
Auto-delete gives us a better solution with less code complexity.
I agree "self delete" is problematic. I wonder how important the ability to fire and forget a script with a dedicated monitor is. I'd (naively?) expect whatever spawns the script to reap its exit status. If it is important, what about fire and forget a script with a dedicated character device? Can't come up with a use case for that within ten seconds. However, we use character devices for all kinds of crap. Food for thought, not a demand.
Allowing a client to run "object-del" against its own monitor adds complex edge cases, as it would be desirable to send the QMP response despite the monitor sending it being deleted. Doing "object-del" alone will also result in orphaning a character device backend instance, as there is no opportunity to run the companion "chardev-del" command.
A simpler way to ensure cleanup is to add the concept of auto-deleting monitor objects. Specifically when the "CHR_EVENT_CLOSED" event is emitted, the equivalent of "object-del" + "chardev-del" can be run internally. Since the transient client has already droppped its monitor connection, there is no synchronization to be concerned about.
If object-del or chardev-del fail, there's no way to report the error. Can they fail?
object-del can fail if
* An object with the specified "id" does not exist. That shouldn't happen in this case but harmless if it odes. * object_del command tries to delete the monitor that is servicing the object_del command. Cannot happen with auto-delete * the monitor has not finished initializing it BH with chardev handlers. Cannot happen if we know we have a live connection already.
chardev-del can fail if
* The chardev with "id" does not exist. SHouldn't happen but is harmless if it does * The chardev reports it is "busy" - aka the frontend is still connected - we just deleted it so cannot happen * Record/replay is in use - a niche use case
So I don't think errors are a problem.
Do we always want to delete both monitor and character device?
IMHO yes they are a pair whose lifetime should be tied together for normal use.
Would we make monitor auto-delete delete its character device if character devices also had an auto-delete feature? [...]