Re: [PATCH] migration: expose per-device state save times via query-migrate

[Peter Xu <peterx@redhat.com>]

On Fri, Apr 17, 2026 at 12:56:59AM +0700, Trieu Huynh wrote:
> From: Trieu Huynh <vikingtc4@gmail.com>
> 
> The stop-and-copy phase pauses the VM and saves all non-iterable device
> states. qemu_savevm_state_non_iterable() already measures per-device
> elapsed time for tracing (trace_vmstate_downtime_save, added in
> commit 3c80f14272), but this information is never stored or surfaced
> to somewhere.
> 
> Expose the result through a new 'device-state-times' list in
> MigrationInfo, filled by qemu_savevm_get_device_state_times() helper
> and returned by query-migrate when status is completed.
> 
> A new QAPI type is introduced:
> DeviceSaveStateTime { 'name': 'str', 'instance-id': 'int', 'save-time': 'int' }
> where 'save-time' is the elapsed time in microseconds.

Hi, Trieu,

Thanks again for your patch, especially during your spare time.

Though I need to say this is another example I want to mention, that QMP is
an API that QEMU relies on a lot, and we're serious on what it exposes.  We
need to justify whatever new info to be exposed.

So if we start to report something in QAPI, we'd better be very certain at
least someone will be consuming this at the very least.  Starting from the
1st day this API got merged, we will need to stick with it and it can be
forever; we can obsolete things, but we need to evaluate risk.  Before that
risk analysis, we better evaluate why an API is needed in the first place.

What is much less controversial is, if you could look at how to improve any
of these numbers reported, say, if we can shrink some device save/load
time, that'll always be a performance improvements.

And just to mention Joao's effort was not discontinued and gone, it's just
done instead by tracepoints here rather than QMP queries (before we're more
confident that we can leverage some new data in query-migrate):

https://lore.kernel.org/all/20231030163346.765724-6-peterx@redhat.com/

Thanks,

-- 
Peter Xu