From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrrAG-0000RH-87 for qemu-devel@nongnu.org; Wed, 26 Jun 2013 10:57:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrrAE-0006yf-5s for qemu-devel@nongnu.org; Wed, 26 Jun 2013 10:57:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrrAD-0006yJ-TQ for qemu-devel@nongnu.org; Wed, 26 Jun 2013 10:57:42 -0400 Message-ID: <51CB0151.5060400@redhat.com> Date: Wed, 26 Jun 2013 16:57:21 +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> <51C9A0D8.6050800@redhat.com> <51C9AF15.8000404@linux.vnet.ibm.com> <51C9AF56.9030800@redhat.com> <51CA03FF.1000806@linux.vnet.ibm.com> <51CA0640.1040507@redhat.com> <51CA3646.8040409@linux.vnet.ibm.com> <51CA8C15.6040501@redhat.com> <51CAE086.506@linux.vnet.ibm.com> <51CAE117.4020300@redhat.com> <51CAF603.7080809@linux.vnet.ibm.com> In-Reply-To: <51CAF603.7080809@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 26/06/2013 16:09, Michael R. Hines ha scritto: > *This requires some steps:* > 1. First, maintain a new data structure: something like > "These memory ranges are 'being unpinned'" - block all potential writes > to these addresses until the unpinning completes. > 2. Once the source unpin completes, send the asynchronous control > channel message > to the other side for unpinning. > 2. Mark the data structure and return and allow the migration to continue > with the next RDMA write. > 3. Upon completion of the unpinning on the destination, > respond to the source that it was finished. > 4. Source then clears the data structure for the successfully unpinned > memory ranges. > 5. At this point, one or more writes may (or may not) be blocking on the > unpinned memory areas and will poll the data structure and find that > the unpinning has completed. > 6. Then issue the new writes and proceed as normal. > 7. Repeat step 1. After more discussion on IRC I think I understand this. It's not trivial, but not super-complex either... it would really be nice to add it to the protocol already in 1.6. Paolo