From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UraIY-0008I6-3A for qemu-devel@nongnu.org; Tue, 25 Jun 2013 16:57:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UraIV-00036n-69 for qemu-devel@nongnu.org; Tue, 25 Jun 2013 16:57:10 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:48251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UraIU-00036Z-Vv for qemu-devel@nongnu.org; Tue, 25 Jun 2013 16:57:07 -0400 Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 25 Jun 2013 14:57:06 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 8AC191FF002E for ; Tue, 25 Jun 2013 14:51:39 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5PKuWsI072920 for ; Tue, 25 Jun 2013 14:56:35 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5PKuWnm015425 for ; Tue, 25 Jun 2013 14:56:32 -0600 Message-ID: <51CA03FF.1000806@linux.vnet.ibm.com> Date: Tue, 25 Jun 2013 16:56:31 -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> <51C99EC6.2050008@linux.vnet.ibm.com> <51C9A0D8.6050800@redhat.com> <51C9AF15.8000404@linux.vnet.ibm.com> <51C9AF56.9030800@redhat.com> In-Reply-To: <51C9AF56.9030800@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 10:55 AM, Paolo Bonzini wrote: > Il 25/06/2013 16:54, Michael R. Hines ha scritto: >>> 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. >> Ok, you got it - no it does not change the protocol. >> I'll use a #define and send it out with a new version for review. > Make sure you send an additional patch on top of these 15. > > Paolo > I was wrong - this does require a protocol extension. This is because the RDMA transfers are asynchronous, and thus we cannot know in advance that it is safe to unregister the memory associated with each individual transfer before the transfer actually completes. While the destination currently uses the protocol to participate in *registering* the page, the destination does not participate in the RDMA transfers themselves, only the source does, and thus would require a new exchange of messages to block and instruct the destination to unpin the memory. - Michael