[{"id":3675483,"web_url":"http://patchwork.ozlabs.org/comment/3675483/","msgid":"","list_archive_url":null,"date":"2026-04-09T19:43:40","subject":"Re: [PATCH v4 0/5] monitor: add dynamic QMP monitor hotplug support","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Thu, Apr 09, 2026 at 09:18:17AM +0200, Christian Brauner wrote:\n> QEMU supports runtime hotplug for chardevs, devices, block backends,\n> and netdevs. Monitors are the only major subsystem that lacks this --\n> all QMP monitors must be configured at launch via -mon or -qmp CLI\n> options.\n> \n> This series adds monitor-add, monitor-remove, and query-monitors QMP\n> commands so that management tools can create independent QMP sessions\n> on demand at runtime.\n\nThere's nothing inherently wrong with your proposal. It is following\nthe standard historical design practice we've taken for enabling\nhotplug/unplug of all the other backend types. Conceptually though\nour historical practice is more of an accident of evolution rather\nthan an ideal state.\n\nBy this I mean we have a general purpose object framework\ninternally and commands '-object', and 'object_add' / 'object_del'\nfor hotplug/unplug in QMP and HMP. Conceptually these could handle\nall of our objects, devices, netdev chardevs, monitors, etc, etc,\nremoving the need for the specialized add/remove QMP commands for\neach backend type, and the specialized CLI argsf. \n\nThe blocker has been lack of time to convert everything/anything,\nsince while the conversions are not especially difficult they are\ncertainly time consuming due to the sheer number of types that\nexist in many cases.\n\n\nI'm thinking the monitor, however, is a decent opportunity to\n\"do the right thing\" from a design POV. We only have three classes\nneeded in QOM, the monitor generic base class, a HMP subclass and\na QMP subclass.\n\nIf we convert QMP/HMP into QOM objects, we could then use the\npre-existing object_add/object_del commands in both HMP and QMP.\n\nI'm not asking you to do that conversion work though. I've\nbeen doing some experimentation myself today to test the\nviability of this idea and it looks promising.\n\nGiven we've got an entire 4 month dev cycle before these\nproposed monitor-add/remove commands could get into a QEMU\nrelease, I think it is worth trialling the QOM conversion\nfor a short while.\n\n> I've implemented a QMP-to-Varlink bridge in systemd. This allows\n> systemd-vmspawn to control virtual machines and containers through a\n> unified Varlink interface. Varlink allows protocol upgrades. For\n> example, it is possible to switch from Varlink to say http. I'm\n> allowing Varlink clients to upgrade from the Varlink interface to the\n> native QMP interface. Such clients get a new monitor assigned that\n> allows them to manage the virtual machine directly via QMP. The main\n> monitor remains unaffected and tied to the generic Varlink interface. We\n> can't pre-allocate monitors as we have no control over how many protocol\n> upgrades we actually get but it won't just be one. And having unused\n> monitors around really isn't ideal either.\n> \n> Having the ability to hotplug monitors would really be helpful. I'm not\n> yet super well-versed in qemu internals so this might be done wrong but\n> testing works so far.\n> \n> My systemd patch that triggered this is at\n> https://github.com/systemd/systemd/pull/41449.\n> \n> The usage pattern mirrors chardev hotplug:\n> \n> -> chardev-add id=qmp-extra backend=socket,...\n> -> monitor-add id=extra-qmp chardev=qmp-extra\n> [client connects to socket, gets QMP greeting, negotiates, sends commands]\n> -> monitor-remove id=extra-qmp\n> -> chardev-remove id=qmp-extra\n\nWith my idea the usage pattern would be basically the same\nflow:\n\n -> chardev-add id=qmp-extra backend=socket,...\n -> object-add qom-type=monitor-qmp id=extra-qmp chardev=qmp-extra\n [client connects to socket, gets QMP greeting, negotiates, sends commands]\n -> object-del id=extra-qmp\n -> chardev-remove id=qmp-extra\n\n> Patches 1-2 add the data model (id field in Monitor) and the\n> infrastructure for safe per-monitor destruction without shutting down\n> the shared dispatcher coroutine.\n> \n> Patch 3 adds the QAPI schema and command handlers.\n> \n> Patches 4-5 add qtest unit tests and a functional e2e test that\n> performs a full hotplug -> connect -> handshake -> unplug cycle.\n\nPatches 2, 4 and 5 would still be desirable even with the QOM\nconversion I'm thinking about.\n\nPatch 1 would be redundant since QOM would give us an ID facility\nas standard.\n\nPatch 3 would be redundant since we'd use object_add/object_del\ninstead.\n\n> \n> > meson test \"qtest-x86_64/qmp-test\" \"func-x86_64-monitor_hotplug\" -v\n> ninja: Entering directory `/home/brauner/src/git/qemu/build'\n> [45/45] Linking target qemu-img\n> 1/2 qemu:func-quick+func-x86_64 / func-x86_64-monitor_hotplug RUNNING\n> >>> QEMU_TEST_QEMU_IMG=/home/brauner/src/git/qemu/build/qemu-img ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MESON_BUILD_ROOT=/home/brauner/src/git/qemu/build LD_LIBRARY_PATH=/home/brauner/src/git/qemu/build/tests/tcg/plugins:/home/brauner/src/git/qemu/build/contrib/plugins:/home/brauner/src/go/deps/raft/.libs/:/home/brauner/src/go/deps/cowsql/.libs/ MALLOC_PERTURB_=165 PYTHONPATH=/home/brauner/src/git/qemu/python:/home/brauner/src/git/qemu/tests/functional QEMU_TEST_GDB=/usr/bin/gdb QEMU_TEST_QEMU_BINARY=/home/brauner/src/git/qemu/build/qemu-system-x86_64 MESON_TEST_ITERATION=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 RUST_BACKTRACE=1 /home/brauner/src/git/qemu/build/pyvenv/bin/python3 /home/brauner/src/git/qemu/tests/functional/generic/test_monitor_hotplug.py\n> 2/2 qemu:qtest+qtest-x86_64 / qtest-x86_64/qmp-test RUNNING\n> >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MALLOC_PERTURB_=244 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 PYTHON=/home/brauner/src/git/qemu/build/pyvenv/bin/python3 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/brauner/src/git/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_BINARY=./qemu-system-x86_64 MESON_TEST_ITERATION=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 RUST_BACKTRACE=1 /home/brauner/src/git/qemu/build/tests/qtest/qmp-test --tap -k\n> ▶ 1/2 test_monitor_hotplug.MonitorHotplug.test_events_after_negotiation OK\n> ▶ 2/2 /x86_64/qmp/protocol OK\n> ▶ 1/2 test_monitor_hotplug.MonitorHotplug.test_hotplug_cycle OK\n> ▶ 1/2 test_monitor_hotplug.MonitorHotplug.test_large_response OK\n> ▶ 2/2 /x86_64/qmp/oob OK\n> ▶ 1/2 test_monitor_hotplug.MonitorHotplug.test_self_removal OK\n> 1/2 qemu:func-quick+func-x86_64 / func-x86_64-monitor_hotplug OK 0.30s 4 subtests passed\n> \n> ▶ 2/2 /x86_64/qmp/preconfig OK\n> ▶ 2/2 /x86_64/qmp/missing-any-arg OK\n> ▶ 2/2 /x86_64/qmp/monitor-add-remove OK\n> ▶ 2/2 /x86_64/qmp/monitor-error-paths OK\n> ▶ 2/2 /x86_64/qmp/monitor-chardev-in-use OK\n> ▶ 2/2 /x86_64/qmp/monitor-remove-cli OK\n> ▶ 2/2 /x86_64/qmp/monitor-remove-hmp OK\n> 2/2 qemu:qtest+qtest-x86_64 / qtest-x86_64/qmp-test OK 1.09s 9 subtests passed\n> \n> Ok: 2\n> Expected Fail: 0\n> Fail: 0\n> Unexpected Pass: 0\n> Skipped: 0\n> Timeout: 0\n> \n> Signed-off-by: Christian Brauner \n> ---\n> Changes in v4:\n> - Move 'dead' field from patch 1 to patch 2 where it is first used.\n> - Allow removal of any QMP monitor, drop the 'dynamic' gate in\n> qmp_monitor_remove(). Drop the 'dynamic' field from struct Monitor\n> and from MonitorInfo entirely since it no longer serves a purpose.\n> - Auto-generate monitor ids (\"mon0\", \"mon1\", ...) for QMP monitors\n> created via CLI without an explicit id, so every QMP monitor is\n> addressable by monitor-remove and always appears with an id in\n> query-monitors output.\n> - Change Since: 11.0 to Since: 11.1 throughout the QAPI schema.\n> - Drop \"GenericError\" from QAPI error descriptions.\n> - Update monitor-remove QAPI doc to reflect that any QMP monitor can\n> be removed, not just dynamically added ones.\n> - Update qtest: test_qmp_monitor_remove_cli now expects success\n> instead of error.\n> - Link to v3: https://patch.msgid.link/20260407-work-qmp-monitor-hotplug-v3-0-cb259800fffb@kernel.org\n> \n> Changes in v3:\n> - Use SPDX license identifier in functional test.\n> - Use framework's socket_dir() helper instead of manual tempfile\n> handling for socket paths in the functional test, drop tearDown().\n> - Tighten struct field comments in monitor-internal.h.\n> - Wrap long qtest_add_func() registration line.\n> - Link to v2: https://patch.msgid.link/20260405-work-qmp-monitor-hotplug-v2-0-ad5bedd2917a@kernel.org\n> \n> Changes in v2:\n> - Fix use-after-free in self-removal path: skip monitor_resume() when\n> the monitor is dead to avoid scheduling a BH against a monitor that\n> is about to be freed by monitor_qmp_destroy().\n> - Hold monitor_lock in monitor_find_by_id() to prevent races with\n> the I/O thread BH that appends to mon_list.\n> - Deduplicate monitor-remove commit message: trim the gcontext/out_watch\n> explanation that repeated the infrastructure commit, reference\n> monitor_cancel_out_watch() instead.\n> - Add missing test descriptions to patch 4 (chardev-in-use, CLI monitor\n> rejection, HMP monitor rejection) and patch 5 (self-removal, large\n> response, events).\n> - Fix cover letter wording.\n> - Link to v1: https://patch.msgid.link/20260402-work-qmp-monitor-hotplug-v1-0-6313a5cdd574@kernel.org\n> \n> ---\n> Christian Brauner (5):\n> monitor: store monitor id in Monitor struct\n> monitor/qmp: add infrastructure for safe dynamic monitor removal\n> qapi: add monitor-add, monitor-remove, query-monitors commands\n> tests/qtest: add tests for dynamic monitor add/remove\n> tests/functional: add e2e test for dynamic QMP monitor hotplug\n> \n> include/monitor/monitor.h | 3 +-\n> monitor/monitor-internal.h | 10 ++\n> monitor/monitor.c | 70 ++++++--\n> monitor/qmp-cmds-control.c | 105 ++++++++++++\n> monitor/qmp.c | 81 +++++++++-\n> qapi/control.json | 97 ++++++++++++\n> tests/functional/generic/meson.build | 1 +\n> tests/functional/generic/test_monitor_hotplug.py | 170 ++++++++++++++++++++\n> tests/qtest/qmp-test.c | 193 +++++++++++++++++++++++\n> 9 files changed, 714 insertions(+), 16 deletions(-)\n> ---\n> base-commit: 6d3e9dddefdd2e8e6a4942ba9399df0e47df21ed\n> change-id: 20260402-work-qmp-monitor-hotplug-fba7c618e3db\n> \n\nWith regards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=a4vBEl2x;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fs9PJ2Sffz1yCv\n\tfor ; Fri, 10 Apr 2026 05:44:36 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wAvID-0001KD-TN; Thu, 09 Apr 2026 15:43:57 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wAvIB-0001Il-FS\n for qemu-devel@nongnu.org; Thu, 09 Apr 2026 15:43:55 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.129.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wAvI7-0006Cv-M3\n for qemu-devel@nongnu.org; Thu, 09 Apr 2026 15:43:55 -0400","from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-117-Ty8jXh2zN_SNx6tJU0P38g-1; Thu,\n 09 Apr 2026 15:43:47 -0400","from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id 3807E1956056; Thu, 9 Apr 2026 19:43:46 +0000 (UTC)","from redhat.com (headnet01.pony-001.prod.iad2.dc.redhat.com\n [10.2.32.101])\n by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with\n ESMTPS\n id D7CFA180036E; Thu, 9 Apr 2026 19:43:43 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1775763830;\n h=from:from:reply-to:reply-to:subject:subject:date:date:\n message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=uEnhudJQ3oNQZ1voyRXp7aWKstzR2pQLbxEvkrSU60k=;\n b=a4vBEl2x7XBZFoap2WalvJJtmnjl9bM7Wqn03W+bvmZXhdwgoJECLVz8QKIZZTeYPOcCxU\n 8nT/xpkVrMUi6I2rRc9J/boifp/xvA1PGggyK1NWpEt72zLqCRI4AqvyR2EVbyfpN9VFDq\n 7Tv5uBDvSspJtc4J4OLpeyX3c/nWltE=","X-MC-Unique":"Ty8jXh2zN_SNx6tJU0P38g-1","X-Mimecast-MFC-AGG-ID":"Ty8jXh2zN_SNx6tJU0P38g_1775763826","Date":"Thu, 9 Apr 2026 20:43:40 +0100","From":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","To":"Christian Brauner ","Cc":"qemu-devel@nongnu.org, Markus Armbruster ,\n Eric Blake , Fabiano Rosas ,\n Laurent Vivier , Paolo Bonzini ,\n Thomas Huth ,\n Philippe =?utf-8?q?Mathieu-Daud=C3=A9?= ","Subject":"Re: [PATCH v4 0/5] monitor: add dynamic QMP monitor hotplug support","Message-ID":"","References":"<20260409-work-qmp-monitor-hotplug-v4-0-89c4fdf69df1@kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260409-work-qmp-monitor-hotplug-v4-0-89c4fdf69df1@kernel.org>","User-Agent":"Mutt/2.2.14 (2025-02-20)","X-Scanned-By":"MIMEDefang 3.4.1 on 10.30.177.93","Received-SPF":"pass client-ip=170.10.129.124;\n envelope-from=berrange@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"7","X-Spam_score":"0.7","X-Spam_bar":"/","X-Spam_report":"(0.7 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.54,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\n RCVD_IN_SBL_CSS=3.335, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,\n RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001,\n SPF_PASS=-0.001 autolearn=no autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Reply-To":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3675697,"web_url":"http://patchwork.ozlabs.org/comment/3675697/","msgid":"<20260410-kupfer-rosten-9d08af140e1a@brauner>","list_archive_url":null,"date":"2026-04-10T07:36:02","subject":"Re: [PATCH v4 0/5] monitor: add dynamic QMP monitor hotplug support","submitter":{"id":82326,"url":"http://patchwork.ozlabs.org/api/people/82326/","name":"Christian Brauner","email":"brauner@kernel.org"},"content":"On Thu, Apr 09, 2026 at 08:43:40PM +0100, Daniel P. Berrangé wrote:\n> On Thu, Apr 09, 2026 at 09:18:17AM +0200, Christian Brauner wrote:\n> > QEMU supports runtime hotplug for chardevs, devices, block backends,\n> > and netdevs. Monitors are the only major subsystem that lacks this --\n> > all QMP monitors must be configured at launch via -mon or -qmp CLI\n> > options.\n> > \n> > This series adds monitor-add, monitor-remove, and query-monitors QMP\n> > commands so that management tools can create independent QMP sessions\n> > on demand at runtime.\n> \n> There's nothing inherently wrong with your proposal. It is following\n> the standard historical design practice we've taken for enabling\n> hotplug/unplug of all the other backend types. Conceptually though\n> our historical practice is more of an accident of evolution rather\n> than an ideal state.\n> \n> By this I mean we have a general purpose object framework\n> internally and commands '-object', and 'object_add' / 'object_del'\n> for hotplug/unplug in QMP and HMP. Conceptually these could handle\n> all of our objects, devices, netdev chardevs, monitors, etc, etc,\n> removing the need for the specialized add/remove QMP commands for\n> each backend type, and the specialized CLI argsf. \n\nIf you actually plan on converting old types you're now left with two\nways of adding objects. And if you plan on ultimately deprecating the\nold format it's going to be very annoying to fade those out.\n\nOr you're not going to convert and then you have blockdev-add and then\nthe new object pattern.\n\nI'm not sure that I see the value in that. Imho, that's just pain for\nnew users. Just providing my opinion here.\n\n> The blocker has been lack of time to convert everything/anything,\n> since while the conversions are not especially difficult they are\n> certainly time consuming due to the sheer number of types that\n> exist in many cases.\n> \n> \n> I'm thinking the monitor, however, is a decent opportunity to\n> \"do the right thing\" from a design POV. We only have three classes\n> needed in QOM, the monitor generic base class, a HMP subclass and\n> a QMP subclass.\n> \n> If we convert QMP/HMP into QOM objects, we could then use the\n> pre-existing object_add/object_del commands in both HMP and QMP.\n> \n> I'm not asking you to do that conversion work though. I've\n> been doing some experimentation myself today to test the\n> viability of this idea and it looks promising.\n\nHow difficult is this to do? I've had bad experiences with projects\npromising to do it all very differently and taking the patch away from\nme and then not following through or like 2 years later or the feature\njust vanished into nothing. I'm not saying this is the case here but I'm\na bit weary of not having any way to move this forward myself other than\n\"any news on this?\" mails. It's frustrating for both sides.\n\nSo if this is doable just give me what you got and let me see whether I\ncan take it over the finish line.\n\nAlso, I really dislike spending a lot of time understanding something\nand it all working and then being told \"actually, let me do this\". I\navoid this like the plague doing this to developers in the kernel.\n\n> Given we've got an entire 4 month dev cycle before these\n> proposed monitor-add/remove commands could get into a QEMU\n> release, I think it is worth trialling the QOM conversion\n> for a short while.\n\nI'm not sure what your governance model is so I'm just going to ask: Is\nthis just a review or is this a project level decision?\n\n> > I've implemented a QMP-to-Varlink bridge in systemd. This allows\n> > systemd-vmspawn to control virtual machines and containers through a\n> > unified Varlink interface. Varlink allows protocol upgrades. For\n> > example, it is possible to switch from Varlink to say http. I'm\n> > allowing Varlink clients to upgrade from the Varlink interface to the\n> > native QMP interface. Such clients get a new monitor assigned that\n> > allows them to manage the virtual machine directly via QMP. The main\n> > monitor remains unaffected and tied to the generic Varlink interface. We\n> > can't pre-allocate monitors as we have no control over how many protocol\n> > upgrades we actually get but it won't just be one. And having unused\n> > monitors around really isn't ideal either.\n> > \n> > Having the ability to hotplug monitors would really be helpful. I'm not\n> > yet super well-versed in qemu internals so this might be done wrong but\n> > testing works so far.\n> > \n> > My systemd patch that triggered this is at\n> > https://github.com/systemd/systemd/pull/41449.\n> > \n> > The usage pattern mirrors chardev hotplug:\n> > \n> > -> chardev-add id=qmp-extra backend=socket,...\n> > -> monitor-add id=extra-qmp chardev=qmp-extra\n> > [client connects to socket, gets QMP greeting, negotiates, sends commands]\n> > -> monitor-remove id=extra-qmp\n> > -> chardev-remove id=qmp-extra\n> \n> With my idea the usage pattern would be basically the same\n> flow:\n> \n> -> chardev-add id=qmp-extra backend=socket,...\n> -> object-add qom-type=monitor-qmp id=extra-qmp chardev=qmp-extra\n> [client connects to socket, gets QMP greeting, negotiates, sends commands]\n> -> object-del id=extra-qmp\n> -> chardev-remove id=qmp-extra\n> \n> > Patches 1-2 add the data model (id field in Monitor) and the\n> > infrastructure for safe per-monitor destruction without shutting down\n> > the shared dispatcher coroutine.\n> > \n> > Patch 3 adds the QAPI schema and command handlers.\n> > \n> > Patches 4-5 add qtest unit tests and a functional e2e test that\n> > performs a full hotplug -> connect -> handshake -> unplug cycle.\n> \n> Patches 2, 4 and 5 would still be desirable even with the QOM\n> conversion I'm thinking about.\n> \n> Patch 1 would be redundant since QOM would give us an ID facility\n> as standard.\n> \n> Patch 3 would be redundant since we'd use object_add/object_del\n> instead.\n> \n> > \n> > > meson test \"qtest-x86_64/qmp-test\" \"func-x86_64-monitor_hotplug\" -v\n> > ninja: Entering directory `/home/brauner/src/git/qemu/build'\n> > [45/45] Linking target qemu-img\n> > 1/2 qemu:func-quick+func-x86_64 / func-x86_64-monitor_hotplug RUNNING\n> > >>> QEMU_TEST_QEMU_IMG=/home/brauner/src/git/qemu/build/qemu-img ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MESON_BUILD_ROOT=/home/brauner/src/git/qemu/build LD_LIBRARY_PATH=/home/brauner/src/git/qemu/build/tests/tcg/plugins:/home/brauner/src/git/qemu/build/contrib/plugins:/home/brauner/src/go/deps/raft/.libs/:/home/brauner/src/go/deps/cowsql/.libs/ MALLOC_PERTURB_=165 PYTHONPATH=/home/brauner/src/git/qemu/python:/home/brauner/src/git/qemu/tests/functional QEMU_TEST_GDB=/usr/bin/gdb QEMU_TEST_QEMU_BINARY=/home/brauner/src/git/qemu/build/qemu-system-x86_64 MESON_TEST_ITERATION=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 RUST_BACKTRACE=1 /home/brauner/src/git/qemu/build/pyvenv/bin/python3 /home/brauner/src/git/qemu/tests/functional/generic/test_monitor_hotplug.py\n> > 2/2 qemu:qtest+qtest-x86_64 / qtest-x86_64/qmp-test RUNNING\n> > >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MALLOC_PERTURB_=244 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 PYTHON=/home/brauner/src/git/qemu/build/pyvenv/bin/python3 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/brauner/src/git/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_BINARY=./qemu-system-x86_64 MESON_TEST_ITERATION=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 RUST_BACKTRACE=1 /home/brauner/src/git/qemu/build/tests/qtest/qmp-test --tap -k\n> > ▶ 1/2 test_monitor_hotplug.MonitorHotplug.test_events_after_negotiation OK\n> > ▶ 2/2 /x86_64/qmp/protocol OK\n> > ▶ 1/2 test_monitor_hotplug.MonitorHotplug.test_hotplug_cycle OK\n> > ▶ 1/2 test_monitor_hotplug.MonitorHotplug.test_large_response OK\n> > ▶ 2/2 /x86_64/qmp/oob OK\n> > ▶ 1/2 test_monitor_hotplug.MonitorHotplug.test_self_removal OK\n> > 1/2 qemu:func-quick+func-x86_64 / func-x86_64-monitor_hotplug OK 0.30s 4 subtests passed\n> > \n> > ▶ 2/2 /x86_64/qmp/preconfig OK\n> > ▶ 2/2 /x86_64/qmp/missing-any-arg OK\n> > ▶ 2/2 /x86_64/qmp/monitor-add-remove OK\n> > ▶ 2/2 /x86_64/qmp/monitor-error-paths OK\n> > ▶ 2/2 /x86_64/qmp/monitor-chardev-in-use OK\n> > ▶ 2/2 /x86_64/qmp/monitor-remove-cli OK\n> > ▶ 2/2 /x86_64/qmp/monitor-remove-hmp OK\n> > 2/2 qemu:qtest+qtest-x86_64 / qtest-x86_64/qmp-test OK 1.09s 9 subtests passed\n> > \n> > Ok: 2\n> > Expected Fail: 0\n> > Fail: 0\n> > Unexpected Pass: 0\n> > Skipped: 0\n> > Timeout: 0\n> > \n> > Signed-off-by: Christian Brauner \n> > ---\n> > Changes in v4:\n> > - Move 'dead' field from patch 1 to patch 2 where it is first used.\n> > - Allow removal of any QMP monitor, drop the 'dynamic' gate in\n> > qmp_monitor_remove(). Drop the 'dynamic' field from struct Monitor\n> > and from MonitorInfo entirely since it no longer serves a purpose.\n> > - Auto-generate monitor ids (\"mon0\", \"mon1\", ...) for QMP monitors\n> > created via CLI without an explicit id, so every QMP monitor is\n> > addressable by monitor-remove and always appears with an id in\n> > query-monitors output.\n> > - Change Since: 11.0 to Since: 11.1 throughout the QAPI schema.\n> > - Drop \"GenericError\" from QAPI error descriptions.\n> > - Update monitor-remove QAPI doc to reflect that any QMP monitor can\n> > be removed, not just dynamically added ones.\n> > - Update qtest: test_qmp_monitor_remove_cli now expects success\n> > instead of error.\n> > - Link to v3: https://patch.msgid.link/20260407-work-qmp-monitor-hotplug-v3-0-cb259800fffb@kernel.org\n> > \n> > Changes in v3:\n> > - Use SPDX license identifier in functional test.\n> > - Use framework's socket_dir() helper instead of manual tempfile\n> > handling for socket paths in the functional test, drop tearDown().\n> > - Tighten struct field comments in monitor-internal.h.\n> > - Wrap long qtest_add_func() registration line.\n> > - Link to v2: https://patch.msgid.link/20260405-work-qmp-monitor-hotplug-v2-0-ad5bedd2917a@kernel.org\n> > \n> > Changes in v2:\n> > - Fix use-after-free in self-removal path: skip monitor_resume() when\n> > the monitor is dead to avoid scheduling a BH against a monitor that\n> > is about to be freed by monitor_qmp_destroy().\n> > - Hold monitor_lock in monitor_find_by_id() to prevent races with\n> > the I/O thread BH that appends to mon_list.\n> > - Deduplicate monitor-remove commit message: trim the gcontext/out_watch\n> > explanation that repeated the infrastructure commit, reference\n> > monitor_cancel_out_watch() instead.\n> > - Add missing test descriptions to patch 4 (chardev-in-use, CLI monitor\n> > rejection, HMP monitor rejection) and patch 5 (self-removal, large\n> > response, events).\n> > - Fix cover letter wording.\n> > - Link to v1: https://patch.msgid.link/20260402-work-qmp-monitor-hotplug-v1-0-6313a5cdd574@kernel.org\n> > \n> > ---\n> > Christian Brauner (5):\n> > monitor: store monitor id in Monitor struct\n> > monitor/qmp: add infrastructure for safe dynamic monitor removal\n> > qapi: add monitor-add, monitor-remove, query-monitors commands\n> > tests/qtest: add tests for dynamic monitor add/remove\n> > tests/functional: add e2e test for dynamic QMP monitor hotplug\n> > \n> > include/monitor/monitor.h | 3 +-\n> > monitor/monitor-internal.h | 10 ++\n> > monitor/monitor.c | 70 ++++++--\n> > monitor/qmp-cmds-control.c | 105 ++++++++++++\n> > monitor/qmp.c | 81 +++++++++-\n> > qapi/control.json | 97 ++++++++++++\n> > tests/functional/generic/meson.build | 1 +\n> > tests/functional/generic/test_monitor_hotplug.py | 170 ++++++++++++++++++++\n> > tests/qtest/qmp-test.c | 193 +++++++++++++++++++++++\n> > 9 files changed, 714 insertions(+), 16 deletions(-)\n> > ---\n> > base-commit: 6d3e9dddefdd2e8e6a4942ba9399df0e47df21ed\n> > change-id: 20260402-work-qmp-monitor-hotplug-fba7c618e3db\n> > \n> \n> With regards,\n> Daniel\n> -- \n> |: https://berrange.com ~~ https://hachyderm.io/@berrange :|\n> |: https://libvirt.org ~~ https://entangle-photo.org :|\n> |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|\n> \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=my1gnUEo;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsTBv0THJz1yGb\n\tfor ; Fri, 10 Apr 2026 17:36:37 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wB6Pb-0005vQ-R1; Fri, 10 Apr 2026 03:36:19 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wB6Pa-0005vH-IJ\n for qemu-devel@nongnu.org; Fri, 10 Apr 2026 03:36:18 -0400","from tor.source.kernel.org ([172.105.4.254])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wB6PY-0008D9-02\n for qemu-devel@nongnu.org; Fri, 10 Apr 2026 03:36:18 -0400","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by tor.source.kernel.org (Postfix) with ESMTP id 9000760125;\n Fri, 10 Apr 2026 07:36:07 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 15B53C19421;\n Fri, 10 Apr 2026 07:36:04 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1775806567;\n bh=sMideR0bB8PUkl/2I9TpfAIKACkXq5AAs7uYqqkYmPs=;\n h=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n b=my1gnUEoHE4T0p3baj3gCczn7jbIrQQgu5MSSz5kufs15ea5MDbrB/j1K26LcehF8\n 3h+IBjnHuMhEmvnTU1z6o+xXDx/z3DKGG2lLEnbdF2fUy9EvjlkKoqGvfaAj36KVue\n VjJkL6dXVfIwNkAizmPFZcp7DWNK5seW3JQbNeMQPoB5tXqA8c1Gx0x7g9hhRhLNSP\n wStNgtiXM14/Rj/doTNcfc0dhhKJ0ehTNOezC+Y5G3ZQo/6YIFJ1JI1hSZnsKt6/1X\n j9F6qw79PxLo9Rogpa0oCakF6eqqZsAMZDmBX/kT/pWjthOtsEXbDDvFb9NLyiiGXw\n LrKn9yD4F8cVQ==","Date":"Fri, 10 Apr 2026 09:36:02 +0200","From":"Christian Brauner ","To":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","Cc":"qemu-devel@nongnu.org, Markus Armbruster ,\n Eric Blake , Fabiano Rosas ,\n Laurent Vivier , Paolo Bonzini ,\n Thomas Huth , Philippe =?utf-8?q?Mathieu-Daud?=\n\t=?utf-8?q?=C3=A9?= ","Subject":"Re: [PATCH v4 0/5] monitor: add dynamic QMP monitor hotplug support","Message-ID":"<20260410-kupfer-rosten-9d08af140e1a@brauner>","References":"<20260409-work-qmp-monitor-hotplug-v4-0-89c4fdf69df1@kernel.org>\n ","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"","Received-SPF":"pass client-ip=172.105.4.254; envelope-from=brauner@kernel.org;\n helo=tor.source.kernel.org","X-Spam_score_int":"-25","X-Spam_score":"-2.6","X-Spam_bar":"--","X-Spam_report":"(-2.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.54,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3675977,"web_url":"http://patchwork.ozlabs.org/comment/3675977/","msgid":"","list_archive_url":null,"date":"2026-04-10T16:25:42","subject":"Re: [PATCH v4 0/5] monitor: add dynamic QMP monitor hotplug support","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Fri, Apr 10, 2026 at 09:36:02AM +0200, Christian Brauner wrote:\n> On Thu, Apr 09, 2026 at 08:43:40PM +0100, Daniel P. Berrangé wrote:\n> > On Thu, Apr 09, 2026 at 09:18:17AM +0200, Christian Brauner wrote:\n> > > QEMU supports runtime hotplug for chardevs, devices, block backends,\n> > > and netdevs. Monitors are the only major subsystem that lacks this --\n> > > all QMP monitors must be configured at launch via -mon or -qmp CLI\n> > > options.\n> > > \n> > > This series adds monitor-add, monitor-remove, and query-monitors QMP\n> > > commands so that management tools can create independent QMP sessions\n> > > on demand at runtime.\n> > \n> > There's nothing inherently wrong with your proposal. It is following\n> > the standard historical design practice we've taken for enabling\n> > hotplug/unplug of all the other backend types. Conceptually though\n> > our historical practice is more of an accident of evolution rather\n> > than an ideal state.\n> > \n> > By this I mean we have a general purpose object framework\n> > internally and commands '-object', and 'object_add' / 'object_del'\n> > for hotplug/unplug in QMP and HMP. Conceptually these could handle\n> > all of our objects, devices, netdev chardevs, monitors, etc, etc,\n> > removing the need for the specialized add/remove QMP commands for\n> > each backend type, and the specialized CLI argsf. \n> \n> If you actually plan on converting old types you're now left with two\n> ways of adding objects. And if you plan on ultimately deprecating the\n> old format it's going to be very annoying to fade those out.\n\nWe have two ways to dealing with this.\n\nA formal deprecation & removal process which lets us fully\nkill off the old way of doing things across 3 releases (1\nyear).\n\n https://www.qemu.org/docs/master/about/deprecated.html\n\nWe use that alot, but for something as fundamental as the\nmonitor I don't think we would take that route as the\nimpact on users is too great. Instead we would follow the\napproach of preserving the existing CLI arg and internally\nrewriting it to the new syntax. So we only have one (new)\ncode path internally, except for a thin shim as the CLI\nlayer for conversion which has minimal long term burden on\nmaintainers.\n\nEventually we're likely to have a clean compat back with\nnew binaries, where we can drop all the legacy cruft from\nthe CLI.\n\n> > The blocker has been lack of time to convert everything/anything,\n> > since while the conversions are not especially difficult they are\n> > certainly time consuming due to the sheer number of types that\n> > exist in many cases.\n> > \n> > \n> > I'm thinking the monitor, however, is a decent opportunity to\n> > \"do the right thing\" from a design POV. We only have three classes\n> > needed in QOM, the monitor generic base class, a HMP subclass and\n> > a QMP subclass.\n> > \n> > If we convert QMP/HMP into QOM objects, we could then use the\n> > pre-existing object_add/object_del commands in both HMP and QMP.\n> > \n> > I'm not asking you to do that conversion work though. I've\n> > been doing some experimentation myself today to test the\n> > viability of this idea and it looks promising.\n> \n> How difficult is this to do? I've had bad experiences with projects\n> promising to do it all very differently and taking the patch away from\n> me and then not following through or like 2 years later or the feature\n> just vanished into nothing. I'm not saying this is the case here but I'm\n> a bit weary of not having any way to move this forward myself other than\n> \"any news on this?\" mails. It's frustrating for both sides.\n> \n> So if this is doable just give me what you got and let me see whether I\n> can take it over the finish line.\n\nI've just posted a series which gets it as far as being able to\nuse -object and object_add. I don't want your use case to be\ndelayed indefinitely - whichever design & impl, I'd want something\nto be mergeable for the next schedule release. \n\n> Also, I really dislike spending a lot of time understanding something\n> and it all working and then being told \"actually, let me do this\". I\n> avoid this like the plague doing this to developers in the kernel.\n\nI'm sorry I didn't notice your series when it was the v1 posting,\nas I would have liked to raise this idea earlier. It is delicate\nbalancing act between being accessible to new contributions, vs\ntrying to align with longer term design preferences.\n\n> > Given we've got an entire 4 month dev cycle before these\n> > proposed monitor-add/remove commands could get into a QEMU\n> > release, I think it is worth trialling the QOM conversion\n> > for a short while.\n> \n> I'm not sure what your governance model is so I'm just going to ask: Is\n> this just a review or is this a project level decision?\n\nThis is just my design opinion as one of many QEMU maintainers,\nalbeit informed by many historical discussions on this topic.\n\nUltimately nothing is final until a patch series is accepted\nand queued by a maintainer.\n\nHopefully others will give some input - I'm especialy looking\nat Markus (CCd) for this as our QAPI & QMP design expert/maintainer.\n\nWith regards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=TtzCl5XK;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fshyR0j06z1y2d\n\tfor ; Sat, 11 Apr 2026 02:26:39 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wBEgI-0001KC-16; Fri, 10 Apr 2026 12:26:06 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wBEgD-0001Jt-Ty\n for qemu-devel@nongnu.org; Fri, 10 Apr 2026 12:26:02 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.133.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wBEgB-0004hY-C4\n for qemu-devel@nongnu.org; Fri, 10 Apr 2026 12:26:01 -0400","from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-456-DtlTV85MPVmdjgRLFh2HEA-1; Fri,\n 10 Apr 2026 12:25:53 -0400","from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id 388261954235; Fri, 10 Apr 2026 16:25:52 +0000 (UTC)","from redhat.com (headnet01.pony-001.prod.iad2.dc.redhat.com\n [10.2.32.101])\n by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with\n ESMTPS\n id 3D13619560AB; Fri, 10 Apr 2026 16:25:45 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1775838357;\n h=from:from:reply-to:reply-to:subject:subject:date:date:\n message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=B80+ptspUNmcChHxTEZ62OeTsDOdbGlVshBRS3l5X+0=;\n b=TtzCl5XK8EgCudT65L5N3igo/WgNx/e3/2XRWCwarFD/9uw/fJOjXG7uIUh4n/E6wDDwZH\n CD+MR7KhM3nq7lq0xG18GvZFkBVkb5fIEgT16ombyFk6OR9KmNkmEYWC/3S9YLW39ZpEi6\n i91y3TmKE5N6XEin5y0KBEHCfw0fgSg=","X-MC-Unique":"DtlTV85MPVmdjgRLFh2HEA-1","X-Mimecast-MFC-AGG-ID":"DtlTV85MPVmdjgRLFh2HEA_1775838352","Date":"Fri, 10 Apr 2026 17:25:42 +0100","From":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","To":"Christian Brauner ","Cc":"qemu-devel@nongnu.org, Markus Armbruster ,\n Eric Blake , Fabiano Rosas ,\n Laurent Vivier , Paolo Bonzini ,\n Thomas Huth ,\n Philippe =?utf-8?q?Mathieu-Daud=C3=A9?= ","Subject":"Re: [PATCH v4 0/5] monitor: add dynamic QMP monitor hotplug support","Message-ID":"","References":"<20260409-work-qmp-monitor-hotplug-v4-0-89c4fdf69df1@kernel.org>\n \n <20260410-kupfer-rosten-9d08af140e1a@brauner>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260410-kupfer-rosten-9d08af140e1a@brauner>","User-Agent":"Mutt/2.2.14 (2025-02-20)","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.12","Received-SPF":"pass client-ip=170.10.133.124;\n envelope-from=berrange@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"7","X-Spam_score":"0.7","X-Spam_bar":"/","X-Spam_report":"(0.7 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.54,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_SBL_CSS=3.335,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Reply-To":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]