Fabiano Rosas <faro...@suse.de> writes: >> Markus Armbruster <arm...@redhat.com> writes: > >> Fabiano Rosas <faro...@suse.de> writes: >> >>> Markus Armbruster <arm...@redhat.com> writes: >>> >>>> Fabiano Rosas <faro...@suse.de> writes: >>>> >>>>> Add capabilities to MigrationParameters. This structure will hold all >>>>> migration options. Capabilities will go away in the next patch. >>>>> >>>>> Also add capabilities to MigrationParameter as the enum needs to be >>>>> kept in sync with MigrationParameters. This affects the parsing of >>>>> migration HMP commands so make the necessary additions there too. >>>>> >>>>> From this point on, both QMP and HMP versions of >>>>> migrate-set-parameters and query-migrate-parameters gain the ability >>>>> to work with capabilities. >>>>> >>>>> With MigrationParameters now having members for each capability, the >>>>> migration capabilities commands (query-migrate-capabilities, >>>>> migrate-set-capabilities) will soon be deprecated. Add a set of >>>>> helpers to convert between the old MigrationCapability representation >>>>> and the new representation as members of MigrationParameters. >>>>> >>>>> Signed-off-by: Fabiano Rosas <faro...@suse.de> >>>> >>>> [...] >>>> >>>>> diff --git a/qapi/migration.json b/qapi/migration.json >>>>> index 40e00fb86e..3d3f5624c5 100644 >>>>> --- a/qapi/migration.json >>>>> +++ b/qapi/migration.json >>>>> @@ -763,7 +763,14 @@ >>>>> 'vcpu-dirty-limit', >>>>> 'mode', >>>>> 'zero-page-detection', >>>>> - 'direct-io'] } >>>>> + 'direct-io', 'xbzrle', 'rdma-pin-all', 'auto-converge', >>>>> + 'zero-blocks', 'events', 'postcopy-ram', 'x-colo', >>>>> + 'release-ram', 'return-path', 'pause-before-switchover', >>>>> + 'multifd', 'dirty-bitmaps', 'postcopy-blocktime', >>>>> + 'late-block-activate', 'x-ignore-shared', >>>>> + 'validate-uuid', 'background-snapshot', >>>>> + 'zero-copy-send', 'postcopy-preempt', >>>>> + 'switchover-ack', 'dirty-limit', 'mapped-ram' ] } >>>> >>>> This is MigrateParameter. Different order than in MigrationParameters. >>>> Intentional? >>>> >>> >>> I think you mean the pre-existing difference in the order of the >>> compression options multifd-*-level? I'll fix that. >> >> I noticed the new members are in a different order than in >> MigrationParameters. I didn't notice the existing members differ, too. >> > > Sorry, I don't see it, we must be looking at different things.
Misunderstanding? Quite possibly on my part! Let's keep the members of MigrationParameter in the same order as the members of MigrationParameters. In case they already are: nevermind! > >>> If it's something else, it eludes my gaze. >> >> No. >> >> Thanks!
