Re: [PATCH v2 16/24] migration: Add capabilities into MigrationParameters

[Fabiano Rosas <farosas@suse.de>]

Markus Armbruster <armbru@redhat.com> writes:

> Fabiano Rosas <farosas@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 <farosas@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.

If it's something else, it eludes my gaze.