All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.