From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTh1-0001vR-KP for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:54:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrTgw-00034V-Qn for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:53:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTgw-00034P-IT for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:53:54 -0400 Message-ID: <51C9A0D8.6050800@redhat.com> Date: Tue, 25 Jun 2013 15:53:28 +0200 From: Paolo Bonzini 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> <51C99EC6.2050008@linux.vnet.ibm.com> In-Reply-To: <51C99EC6.2050008@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-15 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: "Michael R. Hines" 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 Il 25/06/2013 15:44, Michael R. Hines ha scritto: >>> >> 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? Juan found another small nit, so please do send a v12. He liked (with the small change in cancellation) your last three patches, so there is no need to split out patch 13 (as you had it in v10). >> Michael, did you look at the "debugging/getting the protocol ready" mode >> where all pages are unpinned? > > 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. Do those few lines of code change the protocol? If yes, I'll go against all my previous recommendations and suggest a #define. If no, it is fine to leave it for later, but I would still suggest posting the patch on the list just for information. Paolo