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

On Mon, Aug 24, 2026 7:42:20AM -0700, Daniel P. Berrangé wrote:
> 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.

Developers with knowledge of PCI/PCIe/ACPI and system kernels (Linux, Windows,
and BSD) know that the guest VM needs to follow the appropriate protocol to
power off or eject the device from the VM side so that QEMU can safely remove
the device and send the QMP DEVICE_DELETED event to the cloud administrator.

Assume two scenarios:

1. Due to an issue with the guest VM or QEMU, the device is never detected or
used by the guest VM. Especially for ACPI-based hotplug, allowing a forced
detach enables the user or administrator to avoid having an un-detected device
stuck in the VM.

This is safe as device is never used by guest VM kernel.

2. The VM owner may expect QEMU to unplug the device even when the guest VM is
not cooperating. This provides an option with a clear warning: yes, we can
forcibly detach the PCI device, but doing so carries risks.

Thank you very much!

Dongli Zhang

> 
>> 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://urldefense.com/v3/__https://berrange.com__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAJ3UvkOW$ <https://urldefense.com/v3/__https://berrange.com__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAJ3UvkOW$>       ~~        https://urldefense.com/v3/__https://hachyderm.io/@berrange__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qADJDqpwa$ <https://urldefense.com/v3/__https://hachyderm.io/@berrange__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qADJDqpwa$> :|
> |: https://urldefense.com/v3/__https://libvirt.org__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAPWCfpLe$ <https://urldefense.com/v3/__https://libvirt.org__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAPWCfpLe$>          ~~          https://urldefense.com/v3/__https://entangle-photo.org__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAN7fX7fq$ <https://urldefense.com/v3/__https://entangle-photo.org__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAN7fX7fq$> :|
> |: https://urldefense.com/v3/__https://pixelfed.art/berrange__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAH19vj8f$ <https://urldefense.com/v3/__https://pixelfed.art/berrange__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAH19vj8f$>   ~~    https://urldefense.com/v3/__https://fstop138.berrange.com__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAJz0R0XI$ <https://urldefense.com/v3/__https://fstop138.berrange.com__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAJz0R0XI$> :|
>