[{"id":3677344,"web_url":"http://patchwork.ozlabs.org/comment/3677344/","msgid":"<20260414175710.GA136064@fedora>","list_archive_url":null,"date":"2026-04-14T17:57:10","subject":"Re: [PATCH 2/2] block/monitor: add drive_insert HMP command","submitter":{"id":17227,"url":"http://patchwork.ozlabs.org/api/people/17227/","name":"Stefan Hajnoczi","email":"stefanha@redhat.com"},"content":"On Thu, Apr 09, 2026 at 08:01:54AM +0200, mr-083 wrote:\n> Add a drive_insert HMP command that reconnects a host block device file\n> to an existing guest device whose backing store was previously removed\n> with drive_del.\n> \n> After drive_del, the BlockBackend remains attached to the guest device\n> but has no BlockDriverState (shown as \"[not inserted]\" in info block).\n> drive_insert opens the specified file, finds the device's BlockBackend\n> by iterating all backends and matching the attached device ID, then\n> calls blk_insert_bs() to reconnect the backing store.\n> \n> This complements drive_del for non-removable devices (such as NVMe\n> namespaces) where blockdev-change-medium cannot be used. Combined with\n> PCIe AER Surprise Down error injection to trigger a controller reset,\n> this enables complete NVMe disk hot-swap simulation where the guest\n> sees the same device names throughout.\n> \n> Example usage:\n> drive_del drv0 # remove backing store\n> drive_insert ns0 disk.qcow2 # reconnect backing\n> pcie_aer_inject_error rp0 SDN # trigger controller reset\n\nThis approach does not delete the `--device nvme-ns` but instead\nreplaces the BlockBackend's root node so that the existing NVMe\nNamespace changes the underlying storage.\n\nQuestions about this approach:\n1. NVMe AEN is not involved at all?\n2. Does the guest have access to the new storage as soon as drive_insert\n completes and the PCIe AER is just to kick the guest driver (e.g.\n getting it to update the size of the guest Linux block device)?\n\nStefan","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=Fkp/pHsO;\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=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.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 4fwBnl3wycz1xtJ\n\tfor ; Wed, 15 Apr 2026 03:57:47 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wCi0s-0000W2-GS; Tue, 14 Apr 2026 13:57:26 -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 1wCi0q-0000VZ-SO\n for qemu-devel@nongnu.org; Tue, 14 Apr 2026 13:57:24 -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 1wCi0p-0007ts-0K\n for qemu-devel@nongnu.org; Tue, 14 Apr 2026 13:57:24 -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-114-dPsxRGMFM_CbTN7NoCmzKA-1; Tue,\n 14 Apr 2026 13:57:17 -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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id 7BAE5180034E; Tue, 14 Apr 2026 17:57:14 +0000 (UTC)","from localhost (unknown [10.44.50.237])\n by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP\n id 3E72D195608E; Tue, 14 Apr 2026 17:57:12 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1776189440;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=+vzaEKabxdv0/3CjORshcJXEpntjnx8/hX1P+eHVG7A=;\n b=Fkp/pHsO+qjtZpMJgCvXBWyAzyevCbpZ8KMmqaTaomrrzlO8a4GjgHekdkB4n8Bf4MH8U9\n GxRepRxgXQ5FhE01RVJ7SL9v7TfSoEysGQ5R6fP7Tf3Xh9Q1Nlf6xH5rNiWaiaw5aP1UZR\n wee1s9wazsdyuJt3bVUSe2q0IWfagvE=","X-MC-Unique":"dPsxRGMFM_CbTN7NoCmzKA-1","X-Mimecast-MFC-AGG-ID":"dPsxRGMFM_CbTN7NoCmzKA_1776189435","Date":"Tue, 14 Apr 2026 13:57:10 -0400","From":"Stefan Hajnoczi ","To":"mr-083 ","Cc":"qemu-devel@nongnu.org, qemu-block@nongnu.org, its@irrelevant.dk,\n kbusch@kernel.org, mr-083 , kwolf@redhat.com","Subject":"Re: [PATCH 2/2] block/monitor: add drive_insert HMP command","Message-ID":"<20260414175710.GA136064@fedora>","References":"<20260409060155.94704-1-matthieu@min.io>\n <20260409060155.94704-3-matthieu@min.io>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha512;\n protocol=\"application/pgp-signature\"; boundary=\"CPETiYvycK+BqAR0\"","Content-Disposition":"inline","In-Reply-To":"<20260409060155.94704-3-matthieu@min.io>","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.17","Received-SPF":"pass client-ip=170.10.133.124;\n envelope-from=stefanha@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 ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3677348,"web_url":"http://patchwork.ozlabs.org/comment/3677348/","msgid":"<5AEBB39E-A111-4678-9F28-9816D996C514@minio.io>","list_archive_url":null,"date":"2026-04-14T18:02:00","subject":"Re: [PATCH 2/2] block/monitor: add drive_insert HMP command","submitter":{"id":93098,"url":"http://patchwork.ozlabs.org/api/people/93098/","name":"Matthieu Rolla","email":"matthieu@minio.io"},"content":"Hello Stefan,\n\n1. Correct, no AEN involved.The namespace stays attached to the controller throughout. Only the BlockBackend's root node changes, so from the NVMe protocol perspective nothing happened to the namespace topology.\n\n2. Yes, the new storage is accessible immediately after drive_insert at the QEMU block layer level. The SDN is needed to reset the NVMe controller which may have cached an error state from I/O failures during the period when no backing was present. Without the reset, the guest driver continues to see the controller as faulted. The SDN triggers the standard PCIe AER recovery path (freeze → slot reset → restart) which clears the error state and resumes normal I/O.\n\nOne thing to note: since the namespace device stays alive, the guest kernel's block device number is preserved (e.g. /dev/nvme0n1 stays nvme0n1). This avoids the ida_alloc renaming issue that occurs with device_del + device_add when filesystems hold references to the old namespace head.\n\nThanks\n\n\n\t.\t\nMatthieu\nwww.min.io <>\nmatthieu@min.io <> \n\n> On Apr 14, 2026, at 7:57 PM, Stefan Hajnoczi wrote:\n> \n> On Thu, Apr 09, 2026 at 08:01:54AM +0200, mr-083 wrote:\n>> Add a drive_insert HMP command that reconnects a host block device file\n>> to an existing guest device whose backing store was previously removed\n>> with drive_del.\n>> \n>> After drive_del, the BlockBackend remains attached to the guest device\n>> but has no BlockDriverState (shown as \"[not inserted]\" in info block).\n>> drive_insert opens the specified file, finds the device's BlockBackend\n>> by iterating all backends and matching the attached device ID, then\n>> calls blk_insert_bs() to reconnect the backing store.\n>> \n>> This complements drive_del for non-removable devices (such as NVMe\n>> namespaces) where blockdev-change-medium cannot be used. Combined with\n>> PCIe AER Surprise Down error injection to trigger a controller reset,\n>> this enables complete NVMe disk hot-swap simulation where the guest\n>> sees the same device names throughout.\n>> \n>> Example usage:\n>> drive_del drv0 # remove backing store\n>> drive_insert ns0 disk.qcow2 # reconnect backing\n>> pcie_aer_inject_error rp0 SDN # trigger controller reset\n> \n> This approach does not delete the `--device nvme-ns` but instead\n> replaces the BlockBackend's root node so that the existing NVMe\n> Namespace changes the underlying storage.\n> \n> Questions about this approach:\n> 1. NVMe AEN is not involved at all?\n> 2. Does the guest have access to the new storage as soon as drive_insert\n> completes and the PCIe AER is just to kick the guest driver (e.g.\n> getting it to update the size of the guest Linux block device)?\n> \n> Stefan","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 secure) header.d=minio.io header.i=@minio.io header.a=rsa-sha256\n header.s=minio header.b=Z5zpwXNf;\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=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.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 4fwBvn6hhvz1yCv\n\tfor ; Wed, 15 Apr 2026 04:03:00 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wCi5W-0001bu-AD; Tue, 14 Apr 2026 14:02:14 -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 ) id 1wCi5R-0001ZT-Gl\n for qemu-devel@nongnu.org; Tue, 14 Apr 2026 14:02:11 -0400","from mail-wm1-x329.google.com ([2a00:1450:4864:20::329])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from ) id 1wCi5N-0000j1-Qv\n for qemu-devel@nongnu.org; Tue, 14 Apr 2026 14:02:08 -0400","by mail-wm1-x329.google.com with SMTP id\n 5b1f17b1804b1-488b3f8fa2bso60924035e9.1\n for ; Tue, 14 Apr 2026 11:02:03 -0700 (PDT)","from smtpclient.apple\n (2a01cb0014114800d473b7d8f9900c70.ipv6.abo.wanadoo.fr.\n [2a01:cb00:1411:4800:d473:b7d8:f990:c70])\n by smtp.gmail.com with ESMTPSA id\n 5b1f17b1804b1-488ee038752sm67139645e9.9.2026.04.14.11.01.59\n (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);\n Tue, 14 Apr 2026 11:01:59 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=minio.io; s=minio; t=1776189721; x=1776794521; darn=nongnu.org;\n h=references:to:cc:in-reply-to:date:subject:mime-version:message-id\n :from:from:to:cc:subject:date:message-id:reply-to;\n bh=ZJSw28qT4lIaIJCKrCAWX4T+WrGgCglbDv0E1IFC+QM=;\n b=Z5zpwXNf4OkwWLGB815Bb4wKN57SjwJXSzBqJmlCoLiRYtvjswp3/I5N8ZdKCdZNuv\n ss9YELbGyt9gSHJfFQoKyfbzI21Tn5bbqQdUMlDqLKUWZGo24Kr4XjQFMui6xUQugQz2\n XaA4Y9uXqoYhEppQpB6uhS5pEODIhHYk5apr6mCOf/+HibqrF7ObfIbWOiZ6K4nhNB42\n QHDko9vkm+eju4fWXzVr70s0pv1lfVGAFdy7WeR7JRhOQYUu+S0yW/CPng06A7AtYac2\n a1t0t/v/nsckkbX5mSIVIIblbSKhJsurPEpdB202HR8Tu+nPB09SSv1e4ZZ9BHUKoc5N\n kalw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776189721; x=1776794521;\n h=references:to:cc:in-reply-to:date:subject:mime-version:message-id\n :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=ZJSw28qT4lIaIJCKrCAWX4T+WrGgCglbDv0E1IFC+QM=;\n b=LELsmv4ZfxYsHQEBjJy1/VwqotyJHr1y/eh/Yc1ZC5tS00BSmQrmXUW4Ro3otzVoWW\n Do6aWD27S0EpdH+kBA2ActtkESYVjHJWijsK16CR7cmwawv3rq0Ebt5Bnh7BBUygWLqK\n JA4Iym0j2m76uCZe3bYVCYxulCKcZsUzIeNBoYwaUHMMXgNgWNngSXBN52gln5gPtp6K\n Q/CY382Lq7gLDrYAv++ZPUJn77G+mYufWwFHLCuP4z2/LCbDfCn8j4V7bAGiU6p7tHzB\n RB8WaotTTXiP891cHb/kvrr4v2IIyZCvO2IgO+wT0u0qgC87268Ewr9J7UCj5RAO/tDA\n 0mMQ==","X-Gm-Message-State":"AOJu0Yxfr6POb6VlgxxChpR1bPeRNmEpGwChWdxNOnwhQzf56cPz47To\n EU7frdSl5bN+e0MyoNmvuzHKjDZNT6LFC7N5Ha7mtwSLT97r4/oSD5uX4CJmJ/f4krc=","X-Gm-Gg":"AeBDietc7kZLoaCnZFwwMNT7xDzGqRvtzTz0jpCvvmwFys7w1wDIbl4jLQLr3GZfwVM\n nEzWGLvrufTvk+Jk5mDcjosAtKAfv5dPqp+ULPcduKlHSgZldqqTYO7BIjH2FQ6Tp+8TAbnCyLB\n 85FsNwHlkg1z1VhQ8tTB/cL9Otw7m83VhqjqER1dS1sXTlgZ6LEBg7POf6PozM0j2czSMY4dR9C\n 66C0L9sRAcE6MyEs2uRMu6Wh2A6vZa8ijdxzwceBx6MMe2GrJMDCeDrhPHUZm6GHHOmLlgmieJO\n 9wkV/C7gfuOsv6oAmOv6BqQSp7JXq/BPqmQcmHZTqWbEOwZ540DKE5BUA+bjmrc26eCa+sN+Kfz\n 7cFvBhtk9sWmIvK40SJtIBNTzLehPXG/qKXJizbLpYQ+i2c/fVzX6wenoD5sTpZh0qXYz2ZO70Q\n SwZ7xFQfGxkrMD1cHoOVB34b71lNT69rg/xju9kWlPNb2INjzaOCdQGW/BeliL1StwjfUuDb2M3\n gg3nCQloTmHJqgGFj+mpO2/2K4ZCLe5evj1glv3qkCG/4gG/SuELyy4H/IHg0hjEs7cbxHY1Ou9\n WluQwIw=","X-Received":"by 2002:a05:600d:8496:10b0:486:f893:56c6 with SMTP id\n 5b1f17b1804b1-488db8d16aamr133354225e9.10.1776189720985;\n Tue, 14 Apr 2026 11:02:00 -0700 (PDT)","From":"Matthieu Rolla ","Message-Id":"<5AEBB39E-A111-4678-9F28-9816D996C514@minio.io>","Content-Type":"multipart/alternative;\n boundary=\"Apple-Mail=_446220A6-E2D4-43DE-A789-AB2A929A7E5E\"","Mime-Version":"1.0 (Mac OS X Mail 16.0 \\(3864.400.21\\))","Subject":"Re: [PATCH 2/2] block/monitor: add drive_insert HMP command","Date":"Tue, 14 Apr 2026 20:02:00 +0200","In-Reply-To":"<20260414175710.GA136064@fedora>","Cc":"qemu-devel@nongnu.org, qemu-block@nongnu.org, its@irrelevant.dk,\n kbusch@kernel.org, mr-083 , kwolf@redhat.com","To":"Stefan Hajnoczi ","References":"<20260409060155.94704-1-matthieu@min.io>\n <20260409060155.94704-3-matthieu@min.io> <20260414175710.GA136064@fedora>","X-Mailer":"Apple Mail (2.3864.400.21)","Received-SPF":"pass client-ip=2a00:1450:4864:20::329;\n envelope-from=matthieu@minio.io; helo=mail-wm1-x329.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,\n SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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":3677363,"web_url":"http://patchwork.ozlabs.org/comment/3677363/","msgid":"","list_archive_url":null,"date":"2026-04-14T19:05:50","subject":"Re: [PATCH 2/2] block/monitor: add drive_insert HMP command","submitter":{"id":1896,"url":"http://patchwork.ozlabs.org/api/people/1896/","name":"Warner Losh","email":"imp@bsdimp.com"},"content":"On Tue, Apr 14, 2026 at 12:02 PM Matthieu Rolla wrote:\n\n> Hello Stefan,\n>\n> 1. Correct, no AEN involved.The namespace stays attached to the controller\n> throughout. Only the BlockBackend's root node changes, so from the NVMe\n> protocol perspective nothing happened to the namespace topology.\n>\n> 2. Yes, the new storage is accessible immediately after drive_insert at\n> the QEMU block layer level. The SDN is needed to reset the NVMe controller\n> which may have cached an error state from I/O failures during the period\n> when no backing was present. Without the reset, the guest driver continues\n> to see the controller as faulted. The SDN triggers the standard PCIe AER\n> recovery path (freeze → slot reset → restart) which clears the error state\n> and resumes normal I/O.\n>\n> One thing to note: since the namespace device stays alive, the guest\n> kernel's block device number is preserved (e.g. /dev/nvme0n1 stays\n> nvme0n1). This avoids the ida_alloc renaming issue that occurs with\n> device_del + device_add when filesystems hold references to the old\n> namespace head.\n>\n\nOK. I had hoped this would let me test my FreeBSD namespace arrival and\ndeparture messages correctly. I just added the code for AWS (and other VM)\nsupport for attaching / detaching drives and was hoping I could turn this\ninto a regression test, but sounds like no.\n\nI'll have to go look at what the Linux driver does here. Right now Surprise\nDown events just increment a counter on FreeBSD... Will thta work for a\nDPC system too? Or is that not relevant for the current state of the qemu\nart?\n\nWarner\n\n\n>\n> Thanks\n>\n>\n> .\n> *Matthieu*\n> www.min.io\n> matthieu@min.io\n>\n> On Apr 14, 2026, at 7:57 PM, Stefan Hajnoczi wrote:\n>\n> On Thu, Apr 09, 2026 at 08:01:54AM +0200, mr-083 wrote:\n>\n> Add a drive_insert HMP command that reconnects a host block device file\n> to an existing guest device whose backing store was previously removed\n> with drive_del.\n>\n> After drive_del, the BlockBackend remains attached to the guest device\n> but has no BlockDriverState (shown as \"[not inserted]\" in info block).\n> drive_insert opens the specified file, finds the device's BlockBackend\n> by iterating all backends and matching the attached device ID, then\n> calls blk_insert_bs() to reconnect the backing store.\n>\n> This complements drive_del for non-removable devices (such as NVMe\n> namespaces) where blockdev-change-medium cannot be used. Combined with\n> PCIe AER Surprise Down error injection to trigger a controller reset,\n> this enables complete NVMe disk hot-swap simulation where the guest\n> sees the same device names throughout.\n>\n> Example usage:\n> drive_del drv0 # remove backing store\n> drive_insert ns0 disk.qcow2 # reconnect backing\n> pcie_aer_inject_error rp0 SDN # trigger controller reset\n>\n>\n> This approach does not delete the `--device nvme-ns` but instead\n> replaces the BlockBackend's root node so that the existing NVMe\n> Namespace changes the underlying storage.\n>\n> Questions about this approach:\n> 1. NVMe AEN is not involved at all?\n> 2. Does the guest have access to the new storage as soon as drive_insert\n> completes and the PCIe AER is just to kick the guest driver (e.g.\n> getting it to update the size of the guest Linux block device)?\n>\n> Stefan\n>\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=bsdimp-com.20251104.gappssmtp.com\n header.i=@bsdimp-com.20251104.gappssmtp.com header.a=rsa-sha256\n header.s=20251104 header.b=d7l8HOkZ;\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=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.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 4fwDKM2fFWz1yCv\n\tfor ; Wed, 15 Apr 2026 05:06:45 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wCj5O-0004CQ-9B; Tue, 14 Apr 2026 15:06:10 -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 ) id 1wCj5K-0004CA-5C\n for qemu-devel@nongnu.org; Tue, 14 Apr 2026 15:06:06 -0400","from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from ) id 1wCj5H-0002Fs-Jn\n for qemu-devel@nongnu.org; Tue, 14 Apr 2026 15:06:05 -0400","by mail-pg1-x52e.google.com with SMTP id\n 41be03b00d2f7-c70fb6aa323so2241493a12.3\n for ; Tue, 14 Apr 2026 12:06:02 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776193562; cv=none;\n d=google.com; s=arc-20240605;\n b=AFmC1GKujdjRl6IGw4kEzyR7bzJvByQ6GuDQzpgSV3VdL77XFrL0aEhD54hxmeHbqG\n qmNCNN/RHHl+HdJN/OVqyx0d0WBQuO88gIiNDFejEsOAqmC2xAk6sD30snC0GfHwJCXO\n jst0RjQUiUnTE3RonPeeaR8x6jKuznFAn4aMPvaU+vd3CVpLdpLJlpw5nqWSpdlzmg6Z\n g/KWq1Lks5qnzUbsFkdavWCjKv305dhwvrf9JLyCn7Hr8aw7GKob49EaV6+k7Sl3nX+g\n l6ghcBrxyCZBE3Iz+626Ct2oT0Z0PU0HlXevgZjYvh1uE/uAZN1kV6Jap6JdqEaZGvzk\n wibA==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=6/qko1vr7R3DxbWV2D9HRdxI7MCEa6o9N/ckFyJVKBE=;\n fh=UNGpKgCfOypvNTHClK/7fo7nWsSpr9W9Ly/mUH/DYhg=;\n b=IVLolqaf02wTdFv81iH135sdV0Xkb9UMNUP0llwwTCDQ5lYz7T7IComM5PeN5PiO/x\n I/moyw3/Y411GvKdX4S6XN7qIPW+SUGbQKwHfSE9FrufjjtTpMU8seAD0ayh0w585ggE\n 8+jfNetwHuMIhal32i4Z1kLht9tUQLSZj9ZdgP01V5QJc5H96D7Tp4AFYfL3utGttVqN\n TLpEmMTJX+1SxIQaNf+/djPVObS9d/mQrdhUcJJAKNhl8J/+T1F0Njims38ofVgQu4If\n TjTL32pTSdSv/ChPpNZJXOuQiSR1iyS4t3EeM+B+qjV0klP+r+I2ZFTClD2YO2AUSXq5\n aOgQ==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=bsdimp-com.20251104.gappssmtp.com; s=20251104; t=1776193562; x=1776798362;\n darn=nongnu.org;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=6/qko1vr7R3DxbWV2D9HRdxI7MCEa6o9N/ckFyJVKBE=;\n b=d7l8HOkZKGxt2Ix/EidMOkYFqqziryO+OP9cWnb3n++6UpU6+NcIT5if/hMn917rzI\n aLQU2H33cRuw8tGHuMeTdFDhvet6E2jTskCTqfGkhngn7X786d5cDoY8wy3AN+WMr65X\n +yhuoAjhaT0bpzb3qEXX8iK97bzWdyfSM1x9n593FhKBeIKrmY5bX8qM/fQpe2vhUYJY\n 1Oh1+dY+H8Y2cKiptT3Q9tvlDJRqIQrvQxBJ2FfsEj2t4Gl3FYVdW8cfYiWR4prZedDO\n pciH0h/4sqTJIuobFznYs7MQ5XC8yZSNJZy0hXMHnkDkRzG/JezcjbcTpmfJQuKZajr0\n D/qQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776193562; x=1776798362;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=6/qko1vr7R3DxbWV2D9HRdxI7MCEa6o9N/ckFyJVKBE=;\n b=g9vmLBmoauadk9iqQmfInvweErzYmMIcKfcMl/cTeHnOuf97fCaOqDcd3WbMsZIlzz\n Tenf2KohKnLojCP0lqQ4qVyXllT0VHfr4i/gdTv90JLRF60tkB8KfjT8RAsmPUU5HN9c\n ywIdUP6ukQsqD5GnYxD8LYR8nbVhEkf/Yqy70C9nwsVwPGpbV9OaFWRqhAKHiDtfOdo1\n fzDeanK8cR1S5qJKmWAYyv1BztlCL8KP9gauo5c5j3l7KCUTOeXj53dGdUiCGACEYjrG\n OvkTsegyjGt8JMIyJtTGMH+RbKp7MfjJv1YOq02V/xmx0wGfCGDjW9H3L0aFzGfqpxIt\n JHhw==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8uxI+COwSnh1jLna1qkVWWMmD8QbiX/d7SMlQhQUHQRLhtLfIVl9D60O4dOJK9JspWptJdJ3EyO/t3@nongnu.org","X-Gm-Message-State":"AOJu0Yx48hdq4KOlD/jEX+MZE9FUFhh4mHZyOPkTyfLlU+GDqZuNH+qt\n 6OHXV2j+LmF4jJent0jr8q/iICrMJV84aWt5Pud5JANNDq+lv5iOw6iANC6Z5n/z3XVeakAdZh2\n dtWSFP1YQUvfu4yOK8THD2yNyNOVl/b/XSEx7WxM7XQ==","X-Gm-Gg":"AeBDiev2UXBEHA2ObSxPd+ahzKNSpqi3YS7P8FC89tCHpMPDPz4x6gLJ6a+3Cth582u\n rVZx6hMyXuxsUm8Q7bgmCc4zHgZ1drcux5QR7yTJdDACmMh/Zpis1zrYZAjI83psLOvfCZiSK6i\n Ya+sM/sdJVnpU7iSU/LSbVTELhTS1xY50EoHlh9psgqd0ipvAcsZPVUc1U4r5ke7y8nReArv7b1\n qka9CTBeCBwM9kN5cENO8bGKZCu/YgE9p1sKx4V+0kIfWs9UXoJuN59yyoEeg5N5oCK1hX22mVu\n hk69AtjazazHd2uGQg==","X-Received":"by 2002:a17:902:aa09:b0:2aa:d5e5:b136 with SMTP id\n d9443c01a7336-2b2d5a6de64mr136179375ad.38.1776193561577; Tue, 14 Apr 2026\n 12:06:01 -0700 (PDT)","MIME-Version":"1.0","References":"<20260409060155.94704-1-matthieu@min.io>\n <20260409060155.94704-3-matthieu@min.io>\n <20260414175710.GA136064@fedora>\n <5AEBB39E-A111-4678-9F28-9816D996C514@minio.io>","In-Reply-To":"<5AEBB39E-A111-4678-9F28-9816D996C514@minio.io>","From":"Warner Losh ","Date":"Tue, 14 Apr 2026 13:05:50 -0600","X-Gm-Features":"AQROBzDHfb0ZU5AVvAqwivH-NinhU8X3xFnNoZ-SWbei8WlOLKqB7fz1esdekCQ","Message-ID":"\n ","Subject":"Re: [PATCH 2/2] block/monitor: add drive_insert HMP command","To":"Matthieu Rolla ","Cc":"Stefan Hajnoczi , qemu-devel@nongnu.org,\n qemu-block@nongnu.org,\n its@irrelevant.dk, kbusch@kernel.org, mr-083 ,\n kwolf@redhat.com","Content-Type":"multipart/alternative; boundary=\"0000000000004a5b59064f704a18\"","Received-SPF":"none client-ip=2607:f8b0:4864:20::52e;\n envelope-from=wlosh@bsdimp.com; helo=mail-pg1-x52e.google.com","X-Spam_score_int":"-18","X-Spam_score":"-1.9","X-Spam_bar":"-","X-Spam_report":"(-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_NONE=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"}}]