Re: [PATCH 3/8] qdev: Support forced device_del in QMP and HMP

[Daniel P. Berrangé <berrange@xxxxxxxxxx>]

On Sun, Aug 23, 2026 at 06:13:33PM -0700, Dongli Zhang wrote:
> Add an optional force argument to the QMP device_del command and expose it
> in HMP as "device_del -f".
> 
> When force is requested, qdev_unplug() bypasses the pending deletion guard
> and asks the selected hotplug controller to complete removal through its
> force_unplug callback. Controllers that do not implement the callback
> reject the operation.
> 
> Forced removal bypasses guest cooperation.

This sentence is rather missing the punchline....

  Force removal bypasses guest cooperation and may result in guest
  errors, I/O failures, or guest panics. The guest OS cannot be
  trusted after force removal until a full power cycle has been
  performed.

I'm rather on the fence as to whether it is a good idea to enable
this feature or not. If it is used by a cloud admin without knowledge
of the guest owner, its use is liable to lead to hard-to-debug/diagnose
problems in the guest OS.

If a guest OS is not honouring an unplug request and the host owner needs
to force reclaim a resource, power off is always there as the failsafe.

> diff --git a/qapi/qdev.json b/qapi/qdev.json
> index 974cf9c583..cb5b5ad1db 100644
> --- a/qapi/qdev.json
> +++ b/qapi/qdev.json
> @@ -90,6 +90,11 @@
>  #
>  # @id: the device's ID or QOM path
>  #
> +# @force: if true, remove the device without waiting for guest
> +#     cooperation.  The guest may still be using the device.  This can
> +#     cause guest-visible errors, I/O failures, or guest crashes.

I'd want to be warning in a stronger way.


 This is a dangerous operation that can cause guest-visible errors,
 I/O failures, or guest crashes. The guest OS state should not be
 trusted after a forced device removal, until a full power cycle has
 been performed.


> +#     (since 11.2)
> +#
>  # Errors:
>  #     - If @id is not a valid device, DeviceNotFound
>  #
> @@ -101,7 +106,9 @@
>  #    will automatically complete removal for all devices.  If a
>  #    guest-side error in the hot removal process is detected, the
>  #    device will not be removed and a `DEVICE_UNPLUG_GUEST_ERROR`
> -#    event is sent.  Some errors cannot be detected.
> +#    event is sent.  Some errors cannot be detected.  If @force is
> +#    true, guest cooperation is bypassed, but backend cleanup is still
> +#    performed through the device's normal unrealize path.
>  #
>  # Since: 0.14
>  #
> @@ -117,7 +124,7 @@
>  #          "arguments": { "id": "/machine/peripheral-anon/device[0]" } }
>  #     <- { "return": {} }
>  ##
> -{ 'command': 'device_del', 'data': {'id': 'str'} }
> +{ 'command': 'device_del', 'data': {'id': 'str', '*force': 'bool'} }
>  
>  ##
>  # @DEVICE_DELETED:
> diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> index fa3cae246b..ca10a25c46 100644
> --- a/system/qdev-monitor.c
> +++ b/system/qdev-monitor.c
> @@ -956,11 +956,13 @@ void qdev_unplug(DeviceState *dev, bool force, Error 
> **errp)
>      error_propagate(errp, local_err);
>  }

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|