From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrPk1-00033r-JE for qemu-devel@nongnu.org; Tue, 25 Jun 2013 05:40:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrPjw-0007Y7-IE for qemu-devel@nongnu.org; Tue, 25 Jun 2013 05:40:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrPjv-0007Xs-Vp for qemu-devel@nongnu.org; Tue, 25 Jun 2013 05:40:44 -0400 From: Juan Quintela In-Reply-To: <1372125485-11795-14-git-send-email-mrhines@linux.vnet.ibm.com> (mrhines@linux.vnet.ibm.com's message of "Mon, 24 Jun 2013 21:58:03 -0400") References: <1372125485-11795-1-git-send-email-mrhines@linux.vnet.ibm.com> <1372125485-11795-14-git-send-email-mrhines@linux.vnet.ibm.com> Date: Tue, 25 Jun 2013 11:40:38 +0200 Message-ID: <87a9me1qax.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v11 13/15] rdma: allow state transitions between other states besides ACTIVE Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mrhines@linux.vnet.ibm.com Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, pbonzini@redhat.com, chegu_vinod@hp.com, knoel@redhat.com mrhines@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" > > This patch is in preparation for the next ones: Until now the MIG_STATE_SETUP > state was not really a 'formal' state. It has been used as a 'zero' state > and QEMU has been unconditionally transitioning into this state when > the QMP migrate command was called. In preparation for timing this state, > we have to make this state a a 'real' state which actually gets transitioned > from later in the migration_thread() from SETUP => ACTIVE, rather than just > automatically dropping into this state at the beginninig of the migration. > > This means that the state transition function (migration_finish_set_state()) > needs to be capable of transitioning from valid states _other_ than just > MIG_STATE_ACTIVE. > > The function is in fact already capable of doing that, but was not allowing the > old state to be a parameter specified as an input. > > This patch fixes that and only makes the transition if the current state > matches the old state that the caller intended to transition from. > > Tested-by: Michael R. Hines > Signed-off-by: Michael R. Hines Reviewed-by: Juan Quintela