On Mon, 20 Oct 2025 13:22:08 +0200 Markus Armbruster <armbru@redhat.com> wrote:
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.
Could you elaborate why why -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?
[...]