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.

>> If it's something else, it eludes my gaze.
>
> No.
>
> Thanks!

Reply via email to