Re: [PATCH 2/2] block/monitor: add drive_insert HMP command

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

On Thu, Apr 09, 2026 at 08:01:54AM +0200, mr-083 wrote:
> Add a drive_insert HMP command that reconnects a host block device file
> to an existing guest device whose backing store was previously removed
> with drive_del.
> 
> After drive_del, the BlockBackend remains attached to the guest device
> but has no BlockDriverState (shown as "[not inserted]" in info block).
> drive_insert opens the specified file, finds the device's BlockBackend
> by iterating all backends and matching the attached device ID, then
> calls blk_insert_bs() to reconnect the backing store.
> 
> This complements drive_del for non-removable devices (such as NVMe
> namespaces) where blockdev-change-medium cannot be used. Combined with
> PCIe AER Surprise Down error injection to trigger a controller reset,
> this enables complete NVMe disk hot-swap simulation where the guest
> sees the same device names throughout.
> 
> Example usage:
>   drive_del drv0             # remove backing store
>   drive_insert ns0 disk.qcow2  # reconnect backing
>   pcie_aer_inject_error rp0 SDN  # trigger controller reset

This approach does not delete the `--device nvme-ns` but instead
replaces the BlockBackend's root node so that the existing NVMe
Namespace changes the underlying storage.

Questions about this approach:
1. NVMe AEN is not involved at all?
2. Does the guest have access to the new storage as soon as drive_insert
   completes and the PCIe AER is just to kick the guest driver (e.g.
   getting it to update the size of the guest Linux block device)?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]