[{"id":3674373,"web_url":"http://patchwork.ozlabs.org/comment/3674373/","msgid":"","list_archive_url":null,"date":"2026-04-07T11:00:38","subject":"Re: [PATCH v3 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 Tue, Apr 07, 2026 at 09:32:44AM +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> 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\nCan you say if AI agents/LLMs were used in creating these patches ? \n\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 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=O2b40csA;\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 (lists.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 4fqx2645GFz1yGf\n\tfor ; Wed, 08 Apr 2026 05:23:42 +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 1wABW6-0007nC-Gj; Tue, 07 Apr 2026 14:51:14 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wABTk-0003JL-43\n for qemu-devel@nongnu.org; Tue, 07 Apr 2026 14:48:48 -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 1wA4Ar-0008GA-MY\n for qemu-devel@nongnu.org; Tue, 07 Apr 2026 07:00:51 -0400","from mx-prod-mc-05.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-498-BaOfJlOOM-eP7Tv7CoDusw-1; Tue,\n 07 Apr 2026 07:00:45 -0400","from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17])\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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id 1EC8F19560AE; Tue, 7 Apr 2026 11:00:44 +0000 (UTC)","from redhat.com (headnet01.pony-001.prod.iad2.dc.redhat.com\n [10.2.32.101])\n by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with\n ESMTPS\n id C519C1955D84; Tue, 7 Apr 2026 11:00:41 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1775559648;\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:in-reply-to:in-reply-to: references:references;\n bh=WvRynJhQip/PgDiQeybk+Pla8b86NTdSmr7OTQiLRtE=;\n b=O2b40csAD46ofm1zJfQzXbl6bL4EUNnLBugiyksyryCPQbZeukgKn/mN/8uiI8+nkjWioS\n dqUghRw3zIBBv9tHmh/DLRVNMweDfQs0o72ooMbf6C/lrIIeMdHrAHYHLqEL9rtKHWVZYZ\n A6j/qFEkLAgTzl7IVSRE0Une2Rg+jbw=","X-MC-Unique":"BaOfJlOOM-eP7Tv7CoDusw-1","X-Mimecast-MFC-AGG-ID":"BaOfJlOOM-eP7Tv7CoDusw_1775559644","Date":"Tue, 7 Apr 2026 12:00:38 +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 v3 0/5] monitor: add dynamic QMP monitor hotplug support","Message-ID":"","References":"<20260407-work-qmp-monitor-hotplug-v3-0-cb259800fffb@kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20260407-work-qmp-monitor-hotplug-v3-0-cb259800fffb@kernel.org>","User-Agent":"Mutt/2.2.14 (2025-02-20)","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.17","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":"-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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001,\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=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 ","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":3674488,"web_url":"http://patchwork.ozlabs.org/comment/3674488/","msgid":"<20260407-notprogramm-wohlfahrt-be7393963311@brauner>","list_archive_url":null,"date":"2026-04-07T20:57:26","subject":"Re: [PATCH v3 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 Tue, Apr 07, 2026 at 12:00:38PM +0100, Daniel P. Berrangé wrote:\n> On Tue, Apr 07, 2026 at 09:32:44AM +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> > 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> Can you say if AI agents/LLMs were used in creating these patches ? \n\nIn exploring the QEMU codebase and how the QMP protocol is used in other\ncode-bases. So specifically I used it to research:\n\n* Does monitor hotplug already work?\n* Has the idea of monitor hotplug been discussed before?\n* Is there an obvious fundamental reason this cannot work?\n* What does the lifetime of a monitor look like?\n* I used it to review the code I wrote and point out bugs that I then\n fixed myself.\n* I had various research questions around how io-thread interactions\n work and common synchronization primitives in the codebase.\n\nThe code hasn't been written by any coding tool in line with what is\nrequested in the contribution guidelines. I used it to speed up my\nunderstanding of what's going on and to debug things without using the\noutput.","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=oqQBoGwD;\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)"],"X-Greylist":"delayed 1264 seconds by postgrey-1.37 at legolas;\n Wed, 08 Apr 2026 07:21:23 AEST","Received":["from lists.gnu.org (unknown [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 4fqzdv1fyYz1xtJ\n\tfor ; Wed, 08 Apr 2026 07:21:21 +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 1wADWc-0004Ms-2u; Tue, 07 Apr 2026 16:59:54 -0400","from eggs.gnu.org ([209.51.188.92])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wADWa-0004MK-01\n for qemu-devel@nongnu.org; Tue, 07 Apr 2026 16:59:52 -0400","from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25])\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 1wADUR-0000wD-9m\n for qemu-devel@nongnu.org; Tue, 07 Apr 2026 16:57:40 -0400","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by tor.source.kernel.org (Postfix) with ESMTP id A4C02600AC;\n Tue, 7 Apr 2026 20:57:31 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 1F3F1C116C6;\n Tue, 7 Apr 2026 20:57:28 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1775595451;\n bh=4+gNC0s2qQJ4oL9xsc/4G09+rjiF+z+Me6wgkXsSwOE=;\n h=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n b=oqQBoGwDYIQpySY8tjqHqNbhjdtvBDo30jMD/NIWJkrlBEX9SAG6bWv8XVfW/mUDK\n ysE0YFCYHeMSY7/2cfG0CN7fLsCl7Um9FCeGKUxQxODSekJs0FQ78HValqdW41D52w\n pgpO4mPjG6SfXNTls9zzTuPw4sFn5NX40sx33ax7J5LVoEQd+WrYc0Tf8jCXRh5zEP\n NdxEVLRIaQW4wT2pYkljImZSBV0a8EHjX98czmeNa0oFrRnB+yn1IxvDco5D52p9me\n +k3V6l/DvJG16ItpYt/FCyIDuQqpNYtBeTEugFolWFlfC43p+NwA9bXAwKJB8SB1G9\n S9+7G8YnrMJdQ==","Date":"Tue, 7 Apr 2026 22:57:26 +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 v3 0/5] monitor: add dynamic QMP monitor hotplug support","Message-ID":"<20260407-notprogramm-wohlfahrt-be7393963311@brauner>","References":"<20260407-work-qmp-monitor-hotplug-v3-0-cb259800fffb@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=2600:3c04:e001:324:0:1991:8:25;\n envelope-from=brauner@kernel.org; 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 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":3674935,"web_url":"http://patchwork.ozlabs.org/comment/3674935/","msgid":"","list_archive_url":null,"date":"2026-04-08T09:52:25","subject":"Re: [PATCH v3 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 Tue, Apr 07, 2026 at 10:57:26PM +0200, Christian Brauner wrote:\n> On Tue, Apr 07, 2026 at 12:00:38PM +0100, Daniel P. Berrangé wrote:\n> > On Tue, Apr 07, 2026 at 09:32:44AM +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> > > 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> > Can you say if AI agents/LLMs were used in creating these patches ? \n> \n> In exploring the QEMU codebase and how the QMP protocol is used in other\n> code-bases. So specifically I used it to research:\n> \n> * Does monitor hotplug already work?\n> * Has the idea of monitor hotplug been discussed before?\n> * Is there an obvious fundamental reason this cannot work?\n> * What does the lifetime of a monitor look like?\n> * I used it to review the code I wrote and point out bugs that I then\n> fixed myself.\n> * I had various research questions around how io-thread interactions\n> work and common synchronization primitives in the codebase.\n> \n> The code hasn't been written by any coding tool in line with what is\n> requested in the contribution guidelines. I used it to speed up my\n> understanding of what's going on and to debug things without using the\n> output.\n\nThat's all fine, thanks for confirming. I was too suprised by the\nthoroughness of the patches, given your caveat that you were not\nfamiliar with QEMU internals !\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=D5LryQoC;\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 4frY0N5T0kz1xv0\n\tfor ; Thu, 09 Apr 2026 05:24:20 +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 1wAYSk-0003ri-91; Wed, 08 Apr 2026 15:21:18 -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 1wAY3j-00062Z-Sb\n for qemu-devel@nongnu.org; Wed, 08 Apr 2026 14:55:27 -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 1wAPaQ-000478-9J\n for qemu-devel@nongnu.org; Wed, 08 Apr 2026 05:52:40 -0400","from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-223-8h6v8zOiOpOMHrgM6ci78A-1; Wed,\n 08 Apr 2026 05:52:32 -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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id 535C0180028B; Wed, 8 Apr 2026 09:52:31 +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 B95FD19560B1; Wed, 8 Apr 2026 09:52:28 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1775641955;\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=NHgAkaEeXeXO9qay2I4Yl56EdVv/QqtPD1zDtdK+P4g=;\n b=D5LryQoCeWNTqwFbFjv1ijPv8KfsuM5vI1rDFvCf0UpSRhz2mVRxDbyJwkhbVLJPDYnZw/\n kcfhxCf6G4FCyfgBRg1iOcY5P2TqqC0rK55yBebvfNvyt9k90UWXJ9M4cFCdthhkDzvkZQ\n RhdajJ3umQlMxMBCvbPvfwDq1pdJBC8=","X-MC-Unique":"8h6v8zOiOpOMHrgM6ci78A-1","X-Mimecast-MFC-AGG-ID":"8h6v8zOiOpOMHrgM6ci78A_1775641951","Date":"Wed, 8 Apr 2026 10:52:25 +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 v3 0/5] monitor: add dynamic QMP monitor hotplug support","Message-ID":"","References":"<20260407-work-qmp-monitor-hotplug-v3-0-cb259800fffb@kernel.org>\n \n <20260407-notprogramm-wohlfahrt-be7393963311@brauner>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260407-notprogramm-wohlfahrt-be7393963311@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.129.124;\n envelope-from=berrange@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\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=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 ","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":3674978,"web_url":"http://patchwork.ozlabs.org/comment/3674978/","msgid":"<20260408-gemerkt-munter-92aca76e1529@brauner>","list_archive_url":null,"date":"2026-04-08T20:27:04","subject":"Re: [PATCH v3 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 Wed, Apr 08, 2026 at 10:52:25AM +0100, Daniel P. Berrangé wrote:\n> On Tue, Apr 07, 2026 at 10:57:26PM +0200, Christian Brauner wrote:\n> > On Tue, Apr 07, 2026 at 12:00:38PM +0100, Daniel P. Berrangé wrote:\n> > > On Tue, Apr 07, 2026 at 09:32:44AM +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> > > > 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> > > Can you say if AI agents/LLMs were used in creating these patches ? \n> > \n> > In exploring the QEMU codebase and how the QMP protocol is used in other\n> > code-bases. So specifically I used it to research:\n> > \n> > * Does monitor hotplug already work?\n> > * Has the idea of monitor hotplug been discussed before?\n> > * Is there an obvious fundamental reason this cannot work?\n> > * What does the lifetime of a monitor look like?\n> > * I used it to review the code I wrote and point out bugs that I then\n> > fixed myself.\n> > * I had various research questions around how io-thread interactions\n> > work and common synchronization primitives in the codebase.\n> > \n> > The code hasn't been written by any coding tool in line with what is\n> > requested in the contribution guidelines. I used it to speed up my\n> > understanding of what's going on and to debug things without using the\n> > output.\n> \n> That's all fine, thanks for confirming. I was too suprised by the\n> thoroughness of the patches, given your caveat that you were not\n> familiar with QEMU internals !\n\nWell, please don't look at the first version then. :)","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=IrqZxtZq;\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 4frZPR3Zv8z1xy1\n\tfor ; Thu, 09 Apr 2026 06:27: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 1wAZUd-0007fD-Og; Wed, 08 Apr 2026 16:27: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 1wAZUX-0007c8-77\n for qemu-devel@nongnu.org; Wed, 08 Apr 2026 16:27:13 -0400","from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25])\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 1wAZUV-0003qe-In\n for qemu-devel@nongnu.org; Wed, 08 Apr 2026 16:27:12 -0400","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by sea.source.kernel.org (Postfix) with ESMTP id 7094143719;\n Wed, 8 Apr 2026 20:27:09 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 2B3FEC19421;\n Wed, 8 Apr 2026 20:27:06 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1775680029;\n bh=gkoOeBnOMC3lxBY6AwM+cpCNfNX2C//0lZNqmLHcwEE=;\n h=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n b=IrqZxtZqm5m2K2swgLDt36kw5djfR4BKWfvrkgPRttKT8rwArsBY+JBWJQ5Jnz2Wa\n +iSknYZ+LMV/jSJWru55ALHkRRnvhe0NlrrkjVg9wfK+m/IrrzGW4N73JbKWVj49jL\n 5Y9RaiBkVAxnvg+Ej/RuTgT8AUJMs2zHsBFfZFrrFBnuUmzFEaXcwggcTUKz4xaKPp\n wZcZpf23DI9SiE49iAY807LOuYROcROtlg2sT/R2rTFsB91lC0q9G+ddCQebBhar7n\n RwYJp0tP5LHCqjgDgkYQysmvEhQLFxlMkX4F0pjXBQkL3piH/TjfMnvWyTNy/6p4vk\n yI8bURFrvHing==","Date":"Wed, 8 Apr 2026 22:27:04 +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 v3 0/5] monitor: add dynamic QMP monitor hotplug support","Message-ID":"<20260408-gemerkt-munter-92aca76e1529@brauner>","References":"<20260407-work-qmp-monitor-hotplug-v3-0-cb259800fffb@kernel.org>\n \n <20260407-notprogramm-wohlfahrt-be7393963311@brauner>\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=2600:3c0a:e001:78e:0:1991:8:25;\n envelope-from=brauner@kernel.org; helo=sea.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 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"}}]