Daniel P. Berrangé <[email protected]> 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. > > A use case for hotplugging a monitor can involved a user wishing to
Typo: involve > spawn an adhoc script that uses a temporary monitor. The script can ad hoc > ask the management application to hotplug a monitor and pass back a > pre-opened FD using SCM_RIGHTS. In this case the lifetime of the > script is not tied to the management application and thus it is > desirable to have automatic cleanup when the script exits. > > 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 > with sending QMP replies. There is still some internal synchronization > needed, however, between the character device event callback and the > bottom-half that runs the delete. There is a chance that an incoming > client connection may arise before the bottom-half runs, which has > to be checked. Once the monitor object is deleted, the event callback > is unregistered from the character device, eliminating any further > races before the character device is fully deleted. > > This is implemented via a new "close-action=none|delete" property on > the 'monitor-qmp' object. This concept could be extended with further > actions in future, for example: > > * close-action=shutdown - graceful guest shutdown > * close-action=terminate - immediate guest poweroff > * close-action=stop - pause guest CPUs while the monitor is not > connected to any client > > This is left as an exercise for future interested contributors. > > Tested-by: Peter Krempa <[email protected]> > Reviewed-by: Marc-André Lureau <[email protected]> > Acked-by: Markus Armbruster <[email protected]> > Signed-off-by: Daniel P. Berrangé <[email protected]> Happy to fix typos without a respin.
