All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
	lvivier@redhat.com, peterx@redhat.com, dgilbert@redhat.com,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 10/10] migration: [RFC] Use proper types in json
Date: Mon, 06 Nov 2017 15:26:45 +0100	[thread overview]
Message-ID: <87o9ofeb4q.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <87376q10oh.fsf@secure.laptop> (Juan Quintela's message of "Wed, 11 Oct 2017 11:41:34 +0200")

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?

  reply	other threads:[~2017-11-06 14:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-10 18:15 [Qemu-devel] [PATCH 00/10] Make xbzrle_cache_size a migration parameter Juan Quintela
2017-10-10 18:15 ` [Qemu-devel] [PATCH 01/10] migration: Fix migrate_test_apply for multifd parameters Juan Quintela
2017-10-12  5:46   ` Peter Xu
2017-10-18  8:37     ` Juan Quintela
2017-10-10 18:15 ` [Qemu-devel] [PATCH 02/10] migratiom: Remove max_item_age parameter Juan Quintela
2017-10-12  5:46   ` Peter Xu
2017-10-10 18:15 ` [Qemu-devel] [PATCH 03/10] migration: Make cache size elements use the right types Juan Quintela
2017-10-12 10:01   ` Dr. David Alan Gilbert
2017-10-10 18:15 ` [Qemu-devel] [PATCH 04/10] migration: Move xbzrle cache resize error handling to xbzrle_cache_resize Juan Quintela
2017-10-12  5:48   ` Peter Xu
2017-10-10 18:15 ` [Qemu-devel] [PATCH 05/10] migration: Make cache_init() take an error parameter Juan Quintela
2017-10-12  5:55   ` Peter Xu
2017-10-10 18:15 ` [Qemu-devel] [PATCH 06/10] migration: Make sure that we pass the right cache size Juan Quintela
2017-10-12  5:57   ` Peter Xu
2017-10-18  8:45     ` Juan Quintela
2017-10-10 18:15 ` [Qemu-devel] [PATCH 07/10] migration: Don't play games with the requested " Juan Quintela
2017-10-10 18:15 ` [Qemu-devel] [PATCH 08/10] migration: No need to return the size of the cache Juan Quintela
2017-10-10 18:15 ` [Qemu-devel] [PATCH 09/10] migration: Make xbzrle_cache_size a migration parameter Juan Quintela
2017-10-12 12:04   ` Dr. David Alan Gilbert
2017-10-18  8:50     ` Juan Quintela
2017-10-10 18:15 ` [Qemu-devel] [PATCH 10/10] migration: [RFC] Use proper types in json Juan Quintela
2017-10-11  9:28   ` Daniel P. Berrange
2017-10-11  9:41     ` Juan Quintela
2017-11-06 14:26       ` Markus Armbruster [this message]
2017-11-08  9:41         ` Juan Quintela
2017-11-08 10:25           ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o9ofeb4q.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.