On Mon, 20 Oct 2025 13:22:08 +0200 Markus Armbruster <[email protected]> wrote:
> Igor Mammedov <[email protected]> writes: > > > On Thu, 09 Oct 2025 16:55:54 +0200 > > Markus Armbruster <[email protected]> wrote: > > > >> Igor Mammedov <[email protected]> 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? > > [...] >
