From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScaAp-00058H-N2 for qemu-devel@nongnu.org; Thu, 07 Jun 2012 06:42:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScaAn-0002L9-Qt for qemu-devel@nongnu.org; Thu, 07 Jun 2012 06:42:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScaAn-0002L0-IV for qemu-devel@nongnu.org; Thu, 07 Jun 2012 06:42:37 -0400 From: Juan Quintela In-Reply-To: <4FCEB6E3.4060007@redhat.com> (Orit Wasserman's message of "Wed, 06 Jun 2012 04:48:19 +0300") References: <1337691425-6022-1-git-send-email-owasserm@redhat.com> <1337691425-6022-3-git-send-email-owasserm@redhat.com> <871ulz9u5g.fsf@elfo.elfo> <4FCEB6E3.4060007@redhat.com> Date: Thu, 07 Jun 2012 12:41:40 +0200 Message-ID: <87haunjtej.fsf@elfo.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v11 2/9] Add migration capabilites Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Orit Wasserman Cc: peter.maydell@linaro.org, aliguori@us.ibm.com, stefanha@gmail.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, blauwirbel@gmail.com, chegu_vinod@hp.com, avi@redhat.com, pbonzini@redhat.com, eblake@redhat.com Orit Wasserman wrote: > On 06/01/2012 01:57 PM, Juan Quintela wrote: >> Orit Wasserman wrote: >>> Add migration capabiltes that can be queried by the management. >>> The managment can query the source QEMU and the destination QEMU in order to >>> verify both support some migration capability (currently only XBZRLE). >>> The managment can enable a capabilty for the next migration by using >>> migrate_set_parameter command. >>> >>> Signed-off-by: Orit Wasserman >>> +void qmp_migrate_set_parameter(const char *parameter, Error **errp) >>> +{ >>> + MigrationState *s = migrate_get_current(); >>> + int i; >>> + >>> + if (s->state == MIG_STATE_ACTIVE) { >>> + error_set(errp, QERR_MIGRATION_ACTIVE); >>> + return; >>> + } >>> + >>> + for (i = 0; i < MIGRATION_CAPABILITY_MAX; i++) { >>> + if (strcmp(parameter, MigrationCapability_lookup[i]) == 0) { >>> + s->enabled_capabilities[i] = true; >>> + return; >>> + } >>> + } >>> + >>> + error_set(errp, QERR_INVALID_PARAMETER, parameter); >>> +} >> >> Two things here: >> - Is there a way to disable capabilities? it seems no. > > In this implementation we can't disable a capability , do you see a > need to add it ? As we continue adding capabilities, I guess that at least for testing. it is going to be needed. Specially if we decide the path that Anthony suggested: set_capababilities(interesction(caps_source, caps_target)) if we do something like that, and we _know_ that we don't want a capabilitie because we know it dont' work for our load, it sounds like a good idea to have a good way, and the other reason is the next comment. If we could have a capability that is _not_ a bool, we need to be able to assign a value anyways. Notice that I still don't know if we are going to need it. But can see one reason one way or another. > >> - Would we want in the future capabilities that are not "bool"? Just >> asking loud, I haven't thought a lot about this. Fixing it as a >> paramenter, it would make trivial to fix previous comment: cap:true vs >> cap:false, or whatever syntax we want. > That is a good idea I will change it in next patch set. Thanks, Juan.