[10/10] migration: [RFC] Use proper types in json

We use int for everything (int64_t), and then we check that value is
between 0 and 255.  Change it to the valid types.

For qmp, the only real change is that now max_bandwidth allows to use
the k/M/G suffixes.

Signed-off-by: Juan Quintela <quintela@redhat.com>
---
 hmp.c                 | 22 +++++++++++-----------
 migration/migration.c | 49 ++++++++++++++++++++-----------------------------
 qapi/migration.json   | 20 ++++++++++----------
 3 files changed, 41 insertions(+), 50 deletions(-)

On Tue, Oct 10, 2017 at 08:15:42PM +0200, Juan Quintela wrote:
> We use int for everything (int64_t), and then we check that value is
> between 0 and 255.  Change it to the valid types.
> 
> For qmp, the only real change is that now max_bandwidth allows to use
> the k/M/G suffixes.

So on input apps previous would use:

    "max-bandwidth":  1024

ie json numeric field, and would expect to see the same when reading
data back from QEMU.

With this change they could use a string field

    "max-bandwidth":  "1k"

As long as QEMU's JSON parser accepts both number & string values
for the 'size' type it is still backwards compatible if an app
continues to use 1024 instead of "1k"

On *output* though (ie 'info migrate-parameters') this is not
compatible for applications, unless QEMU *always* uses the
numeric format when generating values. ie it must always
report 1024, and never "1k", as apps won't be expecting a string
with suffix.  I can't 100% tell whether this is the case or not,
so CC'ing Markus to confirm if changing "int" to "size" is
guaranteed back-compat in both directions

> Signed-off-by: Juan Quintela <quintela@redhat.com>
> ---
>  hmp.c                 | 22 +++++++++++-----------
>  migration/migration.c | 49 ++++++++++++++++++++-----------------------------
>  qapi/migration.json   | 20 ++++++++++----------
>  3 files changed, 41 insertions(+), 50 deletions(-)
> 
> diff --git a/hmp.c b/hmp.c
> index f73232399a..905dc93aef 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -293,23 +293,23 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict *qdict)
>  
>      if (params) {
>          assert(params->has_compress_level);
> -        monitor_printf(mon, "%s: %" PRId64 "\n",
> +        monitor_printf(mon, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_COMPRESS_LEVEL),
>              params->compress_level);
>          assert(params->has_compress_threads);
> -        monitor_printf(mon, "%s: %" PRId64 "\n",
> +        monitor_printf(mon, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_COMPRESS_THREADS),
>              params->compress_threads);
>          assert(params->has_decompress_threads);
> -        monitor_printf(mon, "%s: %" PRId64 "\n",
> +        monitor_printf(mon, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_DECOMPRESS_THREADS),
>              params->decompress_threads);
>          assert(params->has_cpu_throttle_initial);
> -        monitor_printf(mon, "%s: %" PRId64 "\n",
> +        monitor_printf(mon, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INITIAL),
>              params->cpu_throttle_initial);
>          assert(params->has_cpu_throttle_increment);
> -        monitor_printf(mon, "%s: %" PRId64 "\n",
> +        monitor_printf(mon, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INCREMENT),
>              params->cpu_throttle_increment);
>          assert(params->has_tls_creds);
> @@ -321,28 +321,28 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict *qdict)
>              MigrationParameter_str(MIGRATION_PARAMETER_TLS_HOSTNAME),
>              params->tls_hostname);
>          assert(params->has_max_bandwidth);
> -        monitor_printf(mon, "%s: %" PRId64 " bytes/second\n",
> +        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_MAX_BANDWIDTH),
>              params->max_bandwidth);
>          assert(params->has_downtime_limit);
> -        monitor_printf(mon, "%s: %" PRId64 " milliseconds\n",
> +        monitor_printf(mon, "%s: %" PRIu64 " milliseconds\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_DOWNTIME_LIMIT),
>              params->downtime_limit);
>          assert(params->has_x_checkpoint_delay);
> -        monitor_printf(mon, "%s: %" PRId64 "\n",
> +        monitor_printf(mon, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_X_CHECKPOINT_DELAY),
>              params->x_checkpoint_delay);
>          assert(params->has_block_incremental);
>          monitor_printf(mon, "%s: %s\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_BLOCK_INCREMENTAL),
>              params->block_incremental ? "on" : "off");
> -        monitor_printf(mon, "%s: %" PRId64 "\n",
> +        monitor_printf(mon, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_X_MULTIFD_CHANNELS),
>              params->x_multifd_channels);
> -        monitor_printf(mon, "%s: %" PRId64 "\n",
> +        monitor_printf(mon, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_X_MULTIFD_PAGE_COUNT),
>              params->x_multifd_page_count);
> -        monitor_printf(mon, "%s: %" PRId64 "\n",
> +        monitor_printf(mon, "%s: %" PRIu64 "\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_XBZRLE_CACHE_SIZE),
>              params->xbzrle_cache_size);
>      }
> diff --git a/migration/migration.c b/migration/migration.c
> index fcc0d64625..6d6dcc4e42 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -734,22 +734,20 @@ void qmp_migrate_set_capabilities(MigrationCapabilityStatusList *params,
>  static bool migrate_params_check(MigrationParameters *params, Error **errp)
>  {
>      if (params->has_compress_level &&
> -        (params->compress_level < 0 || params->compress_level > 9)) {
> +        (params->compress_level > 9)) {
>          error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "compress_level",
>                     "is invalid, it should be in the range of 0 to 9");
>          return false;
>      }
>  
> -    if (params->has_compress_threads &&
> -        (params->compress_threads < 1 || params->compress_threads > 255)) {
> +    if (params->has_compress_threads && (params->compress_threads < 1)) {
>          error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
>                     "compress_threads",
>                     "is invalid, it should be in the range of 1 to 255");
>          return false;
>      }
>  
> -    if (params->has_decompress_threads &&
> -        (params->decompress_threads < 1 || params->decompress_threads > 255)) {
> +    if (params->has_decompress_threads && (params->decompress_threads < 1)) {
>          error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
>                     "decompress_threads",
>                     "is invalid, it should be in the range of 1 to 255");
> @@ -774,38 +772,31 @@ static bool migrate_params_check(MigrationParameters *params, Error **errp)
>          return false;
>      }
>  
> -    if (params->has_max_bandwidth &&
> -        (params->max_bandwidth < 0 || params->max_bandwidth > SIZE_MAX)) {
> +    if (params->has_max_bandwidth && (params->max_bandwidth > SIZE_MAX)) {
>          error_setg(errp, "Parameter 'max_bandwidth' expects an integer in the"
>                           " range of 0 to %zu bytes/second", SIZE_MAX);
>          return false;
>      }
>  
>      if (params->has_downtime_limit &&
> -        (params->downtime_limit < 0 ||
> -         params->downtime_limit > MAX_MIGRATE_DOWNTIME)) {
> +        (params->downtime_limit > MAX_MIGRATE_DOWNTIME)) {
>          error_setg(errp, "Parameter 'downtime_limit' expects an integer in "
>                           "the range of 0 to %d milliseconds",
>                           MAX_MIGRATE_DOWNTIME);
>          return false;
>      }
>  
> -    if (params->has_x_checkpoint_delay && (params->x_checkpoint_delay < 0)) {
> -        error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
> -                    "x_checkpoint_delay",
> -                    "is invalid, it should be positive");
> -        return false;
> -    }
> -    if (params->has_x_multifd_channels &&
> -        (params->x_multifd_channels < 1 || params->x_multifd_channels > 255)) {
> +    /* x_checkpoint_delay is now always positive */
> +
> +    if (params->has_x_multifd_channels && (params->x_multifd_channels < 1)) {
>          error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
>                     "multifd_channels",
>                     "is invalid, it should be in the range of 1 to 255");
>          return false;
>      }
>      if (params->has_x_multifd_page_count &&
> -            (params->x_multifd_page_count < 1 ||
> -             params->x_multifd_page_count > 10000)) {
> +        (params->x_multifd_page_count < 1 ||
> +         params->x_multifd_page_count > 10000)) {
>          error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
>                     "multifd_page_count",
>                     "is invalid, it should be in the range of 1 to 10000");
> @@ -2301,33 +2292,33 @@ static Property migration_properties[] = {
>                       send_section_footer, true),
>  
>      /* Migration parameters */
> -    DEFINE_PROP_INT64("x-compress-level", MigrationState,
> +    DEFINE_PROP_UINT8("x-compress-level", MigrationState,
>                        parameters.compress_level,
>                        DEFAULT_MIGRATE_COMPRESS_LEVEL),
> -    DEFINE_PROP_INT64("x-compress-threads", MigrationState,
> +    DEFINE_PROP_UINT8("x-compress-threads", MigrationState,
>                        parameters.compress_threads,
>                        DEFAULT_MIGRATE_COMPRESS_THREAD_COUNT),
> -    DEFINE_PROP_INT64("x-decompress-threads", MigrationState,
> +    DEFINE_PROP_UINT8("x-decompress-threads", MigrationState,
>                        parameters.decompress_threads,
>                        DEFAULT_MIGRATE_DECOMPRESS_THREAD_COUNT),
> -    DEFINE_PROP_INT64("x-cpu-throttle-initial", MigrationState,
> +    DEFINE_PROP_UINT8("x-cpu-throttle-initial", MigrationState,
>                        parameters.cpu_throttle_initial,
>                        DEFAULT_MIGRATE_CPU_THROTTLE_INITIAL),
> -    DEFINE_PROP_INT64("x-cpu-throttle-increment", MigrationState,
> +    DEFINE_PROP_UINT8("x-cpu-throttle-increment", MigrationState,
>                        parameters.cpu_throttle_increment,
>                        DEFAULT_MIGRATE_CPU_THROTTLE_INCREMENT),
> -    DEFINE_PROP_INT64("x-max-bandwidth", MigrationState,
> +    DEFINE_PROP_SIZE("x-max-bandwidth", MigrationState,
>                        parameters.max_bandwidth, MAX_THROTTLE),
> -    DEFINE_PROP_INT64("x-downtime-limit", MigrationState,
> +    DEFINE_PROP_UINT64("x-downtime-limit", MigrationState,
>                        parameters.downtime_limit,
>                        DEFAULT_MIGRATE_SET_DOWNTIME),
> -    DEFINE_PROP_INT64("x-checkpoint-delay", MigrationState,
> +    DEFINE_PROP_UINT32("x-checkpoint-delay", MigrationState,
>                        parameters.x_checkpoint_delay,
>                        DEFAULT_MIGRATE_X_CHECKPOINT_DELAY),
> -    DEFINE_PROP_INT64("x-multifd-channels", MigrationState,
> +    DEFINE_PROP_UINT8("x-multifd-channels", MigrationState,
>                        parameters.x_multifd_channels,
>                        DEFAULT_MIGRATE_MULTIFD_CHANNELS),
> -    DEFINE_PROP_INT64("x-multifd-page-count", MigrationState,
> +    DEFINE_PROP_UINT32("x-multifd-page-count", MigrationState,
>                        parameters.x_multifd_page_count,
>                        DEFAULT_MIGRATE_MULTIFD_PAGE_COUNT),
>      DEFINE_PROP_SIZE("xbzrle-cache-size", MigrationState,
> diff --git a/qapi/migration.json b/qapi/migration.json
> index 830b2e4480..81bd979912 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -656,19 +656,19 @@
>  # Since: 2.4
>  ##
>  { 'struct': 'MigrationParameters',
> -  'data': { '*compress-level': 'int',
> -            '*compress-threads': 'int',
> -            '*decompress-threads': 'int',
> -            '*cpu-throttle-initial': 'int',
> -            '*cpu-throttle-increment': 'int',
> +  'data': { '*compress-level': 'uint8',
> +            '*compress-threads': 'uint8',
> +            '*decompress-threads': 'uint8',
> +            '*cpu-throttle-initial': 'uint8',
> +            '*cpu-throttle-increment': 'uint8',
>              '*tls-creds': 'str',
>              '*tls-hostname': 'str',
> -            '*max-bandwidth': 'int',
> -            '*downtime-limit': 'int',
> -            '*x-checkpoint-delay': 'int',
> +            '*max-bandwidth': 'size',
> +            '*downtime-limit': 'uint64',
> +            '*x-checkpoint-delay': 'uint32',
>              '*block-incremental': 'bool' ,
> -            '*x-multifd-channels': 'int',
> -            '*x-multifd-page-count': 'int',
> +            '*x-multifd-channels': 'uint8',
> +            '*x-multifd-page-count': 'uint32',
>              '*xbzrle-cache-size': 'size' } }
>  
>  ##
> -- 
> 2.13.6
> 
> 

Regards,
Daniel

"Daniel P. Berrange" <berrange@redhat.com> wrote:
> On Tue, Oct 10, 2017 at 08:15:42PM +0200, Juan Quintela wrote:
>> We use int for everything (int64_t), and then we check that value is
>> between 0 and 255.  Change it to the valid types.
>> 
>> For qmp, the only real change is that now max_bandwidth allows to use
>> the k/M/G suffixes.
>
> So on input apps previous would use:
>
>     "max-bandwidth":  1024
>
> ie json numeric field, and would expect to see the same when reading
> data back from QEMU.
>
> With this change they could use a string field
>
>     "max-bandwidth":  "1k"

Actually it is worse than that


if you set:

     "max-bandwidth":  1024

it understand 1024M, and it outputs that big number

      "max-bandwidth":  $((1024*1024*1024))

(no, I don't know the value from memory)

And yes, for migrate_set_parameter, we introduced it on 2.10.  We should
have done the right thing, but  I didn't catch the error (Markus did,
but too late, release were already done)

> As long as QEMU's JSON parser accepts both number & string values
> for the 'size' type it is still backwards compatible if an app
> continues to use 1024 instead of "1k"
>
> On *output* though (ie 'info migrate-parameters') this is not
> compatible for applications, unless QEMU *always* uses the
> numeric format when generating values. ie it must always
> report 1024, and never "1k", as apps won't be expecting a string
> with suffix.  I can't 100% tell whether this is the case or not,
> so CC'ing Markus to confirm if changing "int" to "size" is
> guaranteed back-compat in both directions

This is why I asked.  My *understanding* was that my changes are NOP
if you use the old interface, but I don't claim to be an expert on QAPI.

(qemu) migrate_set_parameter 100
(qemu) info migrate_parameters 
...
max-bandwidth: 104857600 bytes/second
...
(qemu) migrate_set_parameter max-bandwidth 1M
(qemu) info migrate_parameters 
...
max-bandwidth: 1048576 bytes/second
...
(qemu) 

This is the output with my changes applied, so I think that it works
correctly on your example.

Thanks, Juan.

Juan Quintela <quintela@redhat.com> writes:

> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>> On Tue, Oct 10, 2017 at 08:15:42PM +0200, Juan Quintela wrote:
>>> We use int for everything (int64_t), and then we check that value is
>>> between 0 and 255.  Change it to the valid types.
>>> 
>>> For qmp, the only real change is that now max_bandwidth allows to use
>>> the k/M/G suffixes.

Are you sure?

QAPI type 'size' is integer in JSON.  No suffixes.  The QObject input
visitor does suffixes only when visiting v->keyval is true.

>> So on input apps previous would use:
>>
>>     "max-bandwidth":  1024
>>
>> ie json numeric field, and would expect to see the same when reading
>> data back from QEMU.
>>
>> With this change they could use a string field
>>
>>     "max-bandwidth":  "1k"
>
> Actually it is worse than that
>
>
> if you set:
>
>      "max-bandwidth":  1024
>
> it understand 1024M, and it outputs that big number
>
>       "max-bandwidth":  $((1024*1024*1024))
>
> (no, I don't know the value from memory)
>
> And yes, for migrate_set_parameter, we introduced it on 2.10.  We should
> have done the right thing, but  I didn't catch the error (Markus did,
> but too late, release were already done)

I suspect you're talking about *HMP*.  hmp_migrate_set_parameter(), to
be precise:

    case MIGRATION_PARAMETER_MAX_BANDWIDTH:
        p->has_max_bandwidth = true;
        /*
         * Can't use visit_type_size() here, because it
         * defaults to Bytes rather than Mebibytes.
         */
        ret = qemu_strtosz_MiB(valuestr, NULL, &valuebw);
        if (ret < 0 || valuebw > INT64_MAX
            || (size_t)valuebw != valuebw) {
            error_setg(&err, "Invalid size %s", valuestr);
            break;
        }
        p->max_bandwidth = valuebw;
        break;

>> As long as QEMU's JSON parser accepts both number & string values
>> for the 'size' type it is still backwards compatible if an app
>> continues to use 1024 instead of "1k"
>>
>> On *output* though (ie 'info migrate-parameters') this is not
>> compatible for applications, unless QEMU *always* uses the
>> numeric format when generating values. ie it must always
>> report 1024, and never "1k", as apps won't be expecting a string
>> with suffix.  I can't 100% tell whether this is the case or not,
>> so CC'ing Markus to confirm if changing "int" to "size" is
>> guaranteed back-compat in both directions
>
> This is why I asked.  My *understanding* was that my changes are NOP
> if you use the old interface, but I don't claim to be an expert on QAPI.
>
> (qemu) migrate_set_parameter 100
> (qemu) info migrate_parameters 
> ...
> max-bandwidth: 104857600 bytes/second
> ...
> (qemu) migrate_set_parameter max-bandwidth 1M
> (qemu) info migrate_parameters 
> ...
> max-bandwidth: 1048576 bytes/second
> ...
> (qemu) 
>
> This is the output with my changes applied, so I think that it works
> correctly on your example.

This is HMP.  Not a stable interface.  QMP is a stable interface, but it
should not be affected by this patch.  Is your commit message
misleading?

Markus Armbruster <armbru@redhat.com> wrote:
> Juan Quintela <quintela@redhat.com> writes:
>
>> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>>> On Tue, Oct 10, 2017 at 08:15:42PM +0200, Juan Quintela wrote:
>>>> We use int for everything (int64_t), and then we check that value is
>>>> between 0 and 255.  Change it to the valid types.
>>>> 
>>>> For qmp, the only real change is that now max_bandwidth allows to use
>>>> the k/M/G suffixes.
>
> Are you sure?

No.  That is why I ask O:-)

> QAPI type 'size' is integer in JSON.  No suffixes.  The QObject input
> visitor does suffixes only when visiting v->keyval is true.

Aha.  So patch can go in.

>> if you set:
>>
>>      "max-bandwidth":  1024
>>
>> it understand 1024M, and it outputs that big number
>>
>>       "max-bandwidth":  $((1024*1024*1024))
>>
>> (no, I don't know the value from memory)
>>
>> And yes, for migrate_set_parameter, we introduced it on 2.10.  We should
>> have done the right thing, but  I didn't catch the error (Markus did,
>> but too late, release were already done)
>
> I suspect you're talking about *HMP*.  hmp_migrate_set_parameter(), to
> be precise:
>
>     case MIGRATION_PARAMETER_MAX_BANDWIDTH:
>         p->has_max_bandwidth = true;
>         /*
>          * Can't use visit_type_size() here, because it
>          * defaults to Bytes rather than Mebibytes.
>          */
>         ret = qemu_strtosz_MiB(valuestr, NULL, &valuebw);
>         if (ret < 0 || valuebw > INT64_MAX
>             || (size_t)valuebw != valuebw) {
>             error_setg(&err, "Invalid size %s", valuestr);
>             break;
>         }
>         p->max_bandwidth = valuebw;
>         break;

Ok. Understood.  Thanks.


>>> As long as QEMU's JSON parser accepts both number & string values
>>> for the 'size' type it is still backwards compatible if an app
>>> continues to use 1024 instead of "1k"
>>>
>>> On *output* though (ie 'info migrate-parameters') this is not
>>> compatible for applications, unless QEMU *always* uses the
>>> numeric format when generating values. ie it must always
>>> report 1024, and never "1k", as apps won't be expecting a string
>>> with suffix.  I can't 100% tell whether this is the case or not,
>>> so CC'ing Markus to confirm if changing "int" to "size" is
>>> guaranteed back-compat in both directions
>>
>> This is why I asked.  My *understanding* was that my changes are NOP
>> if you use the old interface, but I don't claim to be an expert on QAPI.
>>
>> (qemu) migrate_set_parameter 100
>> (qemu) info migrate_parameters 
>> ...
>> max-bandwidth: 104857600 bytes/second
>> ...
>> (qemu) migrate_set_parameter max-bandwidth 1M
>> (qemu) info migrate_parameters 
>> ...
>> max-bandwidth: 1048576 bytes/second
>> ...
>> (qemu) 
>>
>> This is the output with my changes applied, so I think that it works
>> correctly on your example.
>
> This is HMP.  Not a stable interface.  QMP is a stable interface, but it
> should not be affected by this patch.  Is your commit message
> misleading?

Yeap.  The part about RFC was because I didn't really understood what
was happening here, and wanted "adult supervision".

My reading from your answer is that patch can go in, right?

Thanks, Juan.

Juan Quintela <quintela@redhat.com> writes:

> Markus Armbruster <armbru@redhat.com> wrote:
>> Juan Quintela <quintela@redhat.com> writes:
>>
>>> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>>>> On Tue, Oct 10, 2017 at 08:15:42PM +0200, Juan Quintela wrote:
>>>>> We use int for everything (int64_t), and then we check that value is
>>>>> between 0 and 255.  Change it to the valid types.
>>>>> 
>>>>> For qmp, the only real change is that now max_bandwidth allows to use
>>>>> the k/M/G suffixes.
>>
>> Are you sure?
>
> No.  That is why I ask O:-)

Fair enough :)

>> QAPI type 'size' is integer in JSON.  No suffixes.  The QObject input
>> visitor does suffixes only when visiting v->keyval is true.
>
> Aha.  So patch can go in.
>
>>> if you set:
>>>
>>>      "max-bandwidth":  1024
>>>
>>> it understand 1024M, and it outputs that big number
>>>
>>>       "max-bandwidth":  $((1024*1024*1024))
>>>
>>> (no, I don't know the value from memory)
>>>
>>> And yes, for migrate_set_parameter, we introduced it on 2.10.  We should
>>> have done the right thing, but  I didn't catch the error (Markus did,
>>> but too late, release were already done)
>>
>> I suspect you're talking about *HMP*.  hmp_migrate_set_parameter(), to
>> be precise:
>>
>>     case MIGRATION_PARAMETER_MAX_BANDWIDTH:
>>         p->has_max_bandwidth = true;
>>         /*
>>          * Can't use visit_type_size() here, because it
>>          * defaults to Bytes rather than Mebibytes.
>>          */
>>         ret = qemu_strtosz_MiB(valuestr, NULL, &valuebw);
>>         if (ret < 0 || valuebw > INT64_MAX
>>             || (size_t)valuebw != valuebw) {
>>             error_setg(&err, "Invalid size %s", valuestr);
>>             break;
>>         }
>>         p->max_bandwidth = valuebw;
>>         break;
>
> Ok. Understood.  Thanks.
>
>
>>>> As long as QEMU's JSON parser accepts both number & string values
>>>> for the 'size' type it is still backwards compatible if an app
>>>> continues to use 1024 instead of "1k"
>>>>
>>>> On *output* though (ie 'info migrate-parameters') this is not
>>>> compatible for applications, unless QEMU *always* uses the
>>>> numeric format when generating values. ie it must always
>>>> report 1024, and never "1k", as apps won't be expecting a string
>>>> with suffix.  I can't 100% tell whether this is the case or not,
>>>> so CC'ing Markus to confirm if changing "int" to "size" is
>>>> guaranteed back-compat in both directions
>>>
>>> This is why I asked.  My *understanding* was that my changes are NOP
>>> if you use the old interface, but I don't claim to be an expert on QAPI.
>>>
>>> (qemu) migrate_set_parameter 100
>>> (qemu) info migrate_parameters 
>>> ...
>>> max-bandwidth: 104857600 bytes/second
>>> ...
>>> (qemu) migrate_set_parameter max-bandwidth 1M
>>> (qemu) info migrate_parameters 
>>> ...
>>> max-bandwidth: 1048576 bytes/second
>>> ...
>>> (qemu) 
>>>
>>> This is the output with my changes applied, so I think that it works
>>> correctly on your example.
>>
>> This is HMP.  Not a stable interface.  QMP is a stable interface, but it
>> should not be affected by this patch.  Is your commit message
>> misleading?
>
> Yeap.  The part about RFC was because I didn't really understood what
> was happening here, and wanted "adult supervision".
>
> My reading from your answer is that patch can go in, right?

I think so.