Re: [PATCH RFC V6 22/24] monitor,qdev: Introduce 'device_set' to change admin state of existing devices

[Markus Armbruster <armbru@redhat.com>]

Igor Mammedov <imammedo@redhat.com> writes:

> On Thu, 09 Oct 2025 16:55:54 +0200
> Markus Armbruster <armbru@redhat.com> wrote:
>
>> Igor Mammedov <imammedo@redhat.com> writes:

[...]

>> > It's likely /me who to blame for asking to invent generic
>> > device-set QMP command.
>> > I see another application (beside ARM CPU power-on/off) for it,
>> > PCI devices to simulate powering on/off them at runtime without
>> > actually removing device.  
>> 
>> I prefer generic commands over collecting ad hoc single-purpose
>> commands, too.  Getting the design right can be difficult.
>> 
>> > wrt command,
>> > I'd use only 'id' with it to identify target device
>> > (i.e. no template matching nor QMP path either).
>> > To enforce rule, what user hasn't named explicitly by providing 'id'
>> > isn't meant to be accessed/manged by user later on.   
>> 
>> Works well, except when we need to access / manage onboard devices.
>> That's still an unsolved problem.
>> 
>> > potentially we can invent specialized power_set/get command as
>> > an alternative if it makes design easier.
>> > But then we would be spawning similar commands for other things,
>> > where as device-set would cover it all. But then I might be
>> > over-complicating things by suggesting a generic approach.   
>> 
>> Unclear.
>> 
>> I feel it's best to start the design process with ensvisaged uses.  Can
>> you tell me a bit more about the uses you have in mind?
>
> We have nic failover 'feature'
>    https://www.qemu.org/docs/master/system/virtio-net-failover.html
> to make it work we do abuse hotplug and that poses problem
> during migration, since:
>   - unplugging primary device releases resources (which might not be
>     possible to claim back in case migration failure)

Serious reliability issue with no work-around.

>   - it's similar on destination side, where attempt to hotplug
>     primary might fail die to insufficient resources leaving guest
>     on 'degraded' virtio-net link.

Obvious work-around is failing the migration.  Same as we do when we
can't create devices.

> Idea was that instead of hotplug we can power off primary device,
> (it will still exist and keep resources), initiate migration,
> and then on target do the same starting with primary fully realized
> but powered of (and failing migration early if it can't claim resources,
> safely resuming QEMU on source incl. primary link), and then guest
> failover driver on destination would power primary on as part of
> switching to primary link.

I can see how power on / off makes more sense than hot plug / unplug.

> Above would require -device/device_add support for specifying device's
> power state as minimum.

The obvious way to control a device's power state with -device /
device_add is a qdev property.  Easy enough.

Do we need to control a device's power state after it's created?  If I
understand your use case correctly, the answer is yes.  -device /
device_add can't do that.

qom-set could, but friends don't let friends use it in production.

Any other prior art for controlling device state at run time via QMP?

[...]