From: Orit Wasserman <owasserm@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: peter.maydell@linaro.org, aliguori@us.ibm.com,
quintela@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org,
mdroth@linux.vnet.ibm.com, blauwirbel@gmail.com, avi@redhat.com,
pbonzini@redhat.com, lcapitulino@redhat.com, chegu_vinod@hp.com
Subject: Re: [Qemu-devel] [PATCH 02/11] Add migrate-set-capabilities and query-migrate-capabilities
Date: Mon, 06 Aug 2012 19:49:21 +0300 [thread overview]
Message-ID: <501FF591.1070309@redhat.com> (raw)
In-Reply-To: <501FF348.7020100@redhat.com>
On 08/06/2012 07:39 PM, Eric Blake wrote:
> On 08/06/2012 10:28 AM, Orit Wasserman wrote:
>
>>> That is, BOTH commands end up iterating over a list of caps, and output
>>> identical information in the case where caps exist of 'name: state' for
>>> each capability.
>>>
>
>> The information is different:
>> the first:
>> MigrationCapabilityStatusList *
>> qmp_query_migrate_supported_capabilities(Error **errp)
>> {
>> MigrationCapabilityStatusList *caps_list = g_malloc0(sizeof(*caps_list));
>>
>> caps_list->value = g_malloc(sizeof(*caps_list->value));
>> caps_list->value->capability = MIGRATION_CAPABILITY_XBZRLE;
>> caps_list->value->state = true;
>> caps_list->next = NULL;
>>
>> return caps_list;
>> }
>>
>> the second:
>> MigrationCapabilityStatusList *
>> qmp_query_migrate_supported_capabilities(Error **errp)
>
> I think you meant this for the second:
>
> +MigrationCapabilityStatusList *qmp_query_migrate_capabilities(Error **errp)
> +{
> + MigrationCapabilityStatusList *head = NULL;
> + MigrationCapabilityStatusList *caps;
> + MigrationState *s = migrate_get_current();
> + int i;
> +
> + for (i = 0; i < MIGRATION_CAPABILITY_MAX; i++) {
> + if (head == NULL) {
> + head = g_malloc0(sizeof(*caps));
> + caps = head;
> + } else {
> + caps->next = g_malloc0(sizeof(*caps));
> + caps = caps->next;
> + }
> + caps->value =
> + g_malloc(sizeof(*caps->value));
> + caps->value->capability = i;
> + caps->value->state = s->enabled_capabilities[i];
> + }
>
>> you can look at it as 64bit support one is to know if the processor supports 64 bit
>> the other to know if the OS uses 64 bit
>
> Okay, so the QMP code is currently different (one outputs a list where
> every entry in the list is hard-coded to true, the other outputs a list
> where each entry reflects the current state). But that still doesn't
> address my concern that you don't need two QMP commands.
>
> Merely listing 'xbzrle' in the list is enough to know that 'this
> particular qemu knows how to do xbzrle', and the user is free to ignore
> the additional information of whether it is actually in use at the time
> if all the application cared about was determining the set of known
> capabilities.
>
> Given your argument with 64-bit processing, the same reasoning applies -
> ask for a list of capabilities, and the result will either omit '64bit'
> (the capability is not possible), include '64bit:false' (the capability
> is known by the emulator, but not in use by the guest), or include
> '64bit:true' (the capability is both known and in-use). A user that
> only cares about querying supported capabilities will check whether
> '64bit' is in the list, and throw away the information about whether it
> is on or off (and since the QMP command currently returns a hard-coded
> true, that information is already being discarded via your
> query-migrate-supported-capabilities command). That is, your
> implementation for query-migrate-capabilities is sufficient to satisfy
> both class of users, without needing query-migrate-supported-capabilities.
>
As you represent the user (libvirt) you know the best.
I will remove supported-capabilities commands.
Orit
next prev parent reply other threads:[~2012-08-06 18:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-05 9:13 [Qemu-devel] [PATCH 00/11] Migration next v10 Orit Wasserman
2012-08-05 9:13 ` [Qemu-devel] [PATCH 01/11] Add migration capabilities Orit Wasserman
2012-08-05 9:13 ` [Qemu-devel] [PATCH 02/11] Add migrate-set-capabilities and query-migrate-capabilities Orit Wasserman
2012-08-06 14:26 ` Eric Blake
2012-08-06 16:04 ` Orit Wasserman
2012-08-06 16:14 ` Eric Blake
2012-08-06 16:28 ` Orit Wasserman
2012-08-06 16:39 ` Eric Blake
2012-08-06 16:49 ` Orit Wasserman [this message]
2012-08-05 9:13 ` [Qemu-devel] [PATCH 03/11] Add XBZRLE documentation Orit Wasserman
2012-08-06 15:41 ` Eric Blake
2012-08-05 9:13 ` [Qemu-devel] [PATCH 04/11] Add cache handling functions Orit Wasserman
2012-08-05 9:13 ` [Qemu-devel] [PATCH 05/11] Add uleb encoding/decoding functions Orit Wasserman
2012-08-05 9:13 ` [Qemu-devel] [PATCH 06/11] Add xbzrle_encode_buffer and xbzrle_decode_buffer functions Orit Wasserman
2012-08-05 9:13 ` [Qemu-devel] [PATCH 07/11] Add XBZRLE to ram_save_block and ram_save_live Orit Wasserman
2012-08-05 9:13 ` [Qemu-devel] [PATCH 08/11] Add migrate_set_cache_size command Orit Wasserman
2012-08-06 15:46 ` Eric Blake
2012-08-05 9:13 ` [Qemu-devel] [PATCH 09/11] Add migration accounting for normal and duplicate pages Orit Wasserman
2012-08-06 15:52 ` Eric Blake
2012-08-05 9:13 ` [Qemu-devel] [PATCH 10/11] Add XBZRLE statistics Orit Wasserman
2012-08-06 15:55 ` Eric Blake
2012-08-05 9:13 ` [Qemu-devel] [PATCH 11/11] Restart optimization on stage3 update version Orit Wasserman
-- strict thread matches above, loose matches on Subject: below --
2012-08-02 12:44 [Qemu-devel] [PATCH 00/11] Migration next v9 Orit Wasserman
2012-08-02 12:44 ` [Qemu-devel] [PATCH 02/11] Add migrate-set-capabilities and query-migrate-capabilities Orit Wasserman
2012-08-03 17:22 ` Luiz Capitulino
2012-08-01 18:01 [Qemu-devel] [PULL 00/11] Migration next Juan Quintela
2012-08-01 18:01 ` [Qemu-devel] [PATCH 02/11] Add migrate-set-capabilities and query-migrate-capabilities Juan Quintela
2012-07-31 20:05 [Qemu-devel] [PATCH 02/11] Add migrate_set_capabilities " Orit Wasserman
2012-08-01 7:08 ` [Qemu-devel] [PATCH 02/11] Add migrate-set-capabilities " Orit Wasserman
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=501FF591.1070309@redhat.com \
--to=owasserm@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=chegu_vinod@hp.com \
--cc=eblake@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).