On Fri, Apr 24, 2026 at 09:17:21AM +0200, Markus Armbruster wrote: > Peter Xu <[email protected]> writes: > > > Currently, mgmt can only query for remaining RAM, > > Remind me: how?
It is the same command, as mentioned in [1] below. I'll enrich the commit message here to explain. > > > not system-wise remaining > > data. It was not a problem before, because for a very long time RAM was > > the only part that matters. > > > > After VFIO migrations landed upstream, it may not be true anymore > > especially considering that there can be GPU devices that contain GBs of > > device states. > > > > Add a new "remaining" field in query-migrate results, reflecting > > system-wise remaining data, which will include everything (e.g. VFIO). > > "system-wise"? Do you mean "system-wide"? Maybe "total"? Since "total" has been used elsewhere, I'll use "system-wide", hoping that's easier to digest. > > > > This information will be useful for mgmt to implement generic way of stall > > detection that covers all system resources. Say, when system remaining > > data does not decrease anymore for a relatively long period of time, then > > it may mean that there is a challenge of converging, so mgmt can act based > > on how this value changes over time (especially if sampled after each > > migration iteration). > > > > Before this patch, "expected_downtime" almost played this role. For > > example, by monitoring "expected_downtime" at the beginning of each > > iteration can in most cases also reflect the progress of migration > > system-wise. Said that, "expected_downtime" was always calculated based on > > a bandwidth value that can fluctuate a lot if avail-switchover-bandwidth is > > not used. This new "remaining" field will remove that part of uncertainty > > for mgmt. > > > > With the new field, HMP "info migrate" now reports this: > > > > (qemu) info migrate > > Status: active > > Time (ms): total=12080, setup=14, exp_down=300 > > Remaining: 1.36 GiB <------------------- newline > > "Newline" is ASCI character '\n'. I guess you mean "this is the new > line". Yes. I'll remove this "<----..." if it causes any confusion. > > > RAM info: > > Throughput (Mbps): 840.50 > > Sizes: pagesize=4 KiB, total=4.02 GiB > > Transfers: transferred=1.18 GiB, remain=1.36 GiB > > Channels: precopy=1.18 GiB, multifd=0 B, postcopy=0 B > > Page Types: normal=307923, zero=388148 > > Page Rates (pps): transfer=25660 > > Others: dirty_syncs=1 > > > > It should be the same value as RAM's remaining report when VFIO is not > > involved, and it should report more than that when VFIO is involved. > > "RAM's remaining report" is the "remain=1.36 GiB" part, isn't it? [1] Correct. > > > Cc: Markus Armbruster <[email protected]> > > Reviewed-by: Juraj Marcin <[email protected]> > > Reviewed-by: Dr. David Alan Gilbert <[email protected]> > > Signed-off-by: Peter Xu <[email protected]> > > --- > > qapi/migration.json | 4 ++++ > > migration/migration-hmp-cmds.c | 5 +++++ > > migration/migration.c | 7 +++++++ > > 3 files changed, 16 insertions(+) > > > > diff --git a/qapi/migration.json b/qapi/migration.json > > index e3ad3f0604..a6e24b5685 100644 > > --- a/qapi/migration.json > > +++ b/qapi/migration.json > > @@ -300,6 +300,9 @@ > > # average memory load of the virtual CPU indirectly. Note that > > # zero means guest doesn't dirty memory. (Since 8.1) > > # > > +# @remaining: amount of bytes remaining to be migrated system-wise, > > +# includes both RAM and all devices (like VFIO). (Since 11.1) > > +# > > # Features: > > # > > # @unstable: Members @postcopy-latency, @postcopy-vcpu-latency, > > @@ -310,6 +313,7 @@ > > ## > > { 'struct': 'MigrationInfo', > > 'data': {'*status': 'MigrationStatus', '*ram': 'MigrationRAMStats', > > + '*remaining': 'uint64', > > It's a byte count, so let's make it 'size'. Will do. Since this will be the last functional change so far on the whole series, and the update seems to be pretty under control (say, qapi schema.py generates same c code for both "size" and "uint64"), could I request an ACK on this one with a short diff below, instead of reposting the whole series? The diff attached here (I'll also fix the commit messages on e.g. system-wide wordings if I'll not repost): diff --git a/qapi/migration.json b/qapi/migration.json index b7518b29c6..c701ef1cf5 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -300,7 +300,7 @@ # average memory load of the virtual CPU indirectly. Note that # zero means guest doesn't dirty memory. (Since 8.1) # -# @remaining: amount of bytes remaining to be migrated system-wise, +# @remaining: amount of bytes remaining to be migrated system-wide, # includes both RAM and all devices (like VFIO). (Since 11.1) # # Features: @@ -313,7 +313,7 @@ ## { 'struct': 'MigrationInfo', 'data': {'*status': 'MigrationStatus', '*ram': 'MigrationRAMStats', - '*remaining': 'uint64', + '*remaining': 'size', '*vfio': 'VfioStats', '*xbzrle-cache': 'XBZRLECacheStats', '*total-time': 'int', ===8<==== The complete new version of patch is here (I updated quite a few places on the commit message): https://gitlab.com/peterx/qemu/-/commit/86d973360890cecc564a4a5bcf9a01b9efde368a Thanks, -- Peter Xu
