Re: [PATCH 3/8] qdev: Support forced device_del in QMP and HMP
Daniel P. Berrangé <[email protected]>
| Newsgroups | org.xenproject.lists.xen-devel,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <[email protected]> |
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 :|