From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTaQ-0006AZ-6T for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:47:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrTaM-0000or-Tv for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:47:10 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:49595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTY3-0007vO-4O for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:44:43 -0400 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 25 Jun 2013 09:44:42 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id A91B9C90043 for ; Tue, 25 Jun 2013 09:44:38 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5PDid7352625510 for ; Tue, 25 Jun 2013 09:44:39 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5PDidp9029721 for ; Tue, 25 Jun 2013 09:44:39 -0400 Message-ID: <51C99EC6.2050008@linux.vnet.ibm.com> Date: Tue, 25 Jun 2013 09:44:38 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <1372125485-11795-1-git-send-email-mrhines@linux.vnet.ibm.com> <1372125485-11795-15-git-send-email-mrhines@linux.vnet.ibm.com> <8761x21pvx.fsf@elfo.elfo> <51C96D39.2020603@redhat.com> In-Reply-To: <51C96D39.2020603@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@us.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, chegu_vinod@hp.com, knoel@redhat.com On 06/25/2013 06:13 AM, Paolo Bonzini wrote: > Il 25/06/2013 11:49, Juan Quintela ha scritto: >> mrhines@linux.vnet.ibm.com wrote: >>> From: "Michael R. Hines" >>> >>> As described in the previous patch, until now, the MIG_STATE_SETUP >>> state was not really a 'formal' state. It has been used as a 'zero' state >>> (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning >>> into this state when the QMP migration command was called. Instead we want to >>> introduce MIG_STATE_NONE, which is our starting state in the state machine, and >>> then immediately transition into the MIG_STATE_SETUP state when the QMP migrate >>> command is issued. >>> >>> In order to do this, we must delay the transition into MIG_STATE_ACTIVE until >>> later in the migration_thread(). This is done to be able to timestamp the amount of >>> time spent in the SETUP state for proper accounting to the user during >>> an RDMA migration. >>> >>> Furthermore, the management software, until now, has never been aware of the >>> existence of the SETUP state whatsoever. This must change, because, timing of this >>> state implies that the state actually exists. >>> >>> These two patches cannot be separated because the 'query_migrate' QMP >>> switch statement needs to know how to handle this new state transition. >>> >>> Tested-by: Michael R. Hines >>> Signed-off-by: Michael R. Hines >>> @@ -316,6 +321,7 @@ static void migrate_fd_cancel(MigrationState *s) >>> { >>> DPRINTF("cancelling migration\n"); >>> >>> + migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_CANCELLED); >>> migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED); >>> } >> This chunk is wrong. >> >> we can call qme_migrate_cancel() at any point, and it is going to be >> called normally from MIG_STATE_ACTIVE. >> >> migrate_set_satet(s, s->state, MIG_STATE_CANCELLED) >> >> should do the trick. Or something like that, what do you think? > I don't like the three-arguments migrate_set_state, but I don't have any > better idea. > > With Juan's modification, it is fine (but not reviewed-by me :)). While > you resend, the first 13 patches of v10 can be merged (pull request). > You can then rebase the last three on top. So, I should send a v11 before Juan applies and generates the pull request? Did I understand correctly? > Michael, did you look at the "debugging/getting the protocol ready" mode > where all pages are unpinned? > > Paolo > We did not come up with a design on how such a mode would be exposed to the user. Implementing this in migration-rdma.c is just a few lines of code, but without a clear use case in this patch series, I've not chosen expose it to the user yet without some kind of agreement with you guys. Recommendations?