From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URpVM-00027w-Li for qemu-devel@nongnu.org; Mon, 15 Apr 2013 15:55:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URpVJ-0004Vw-Od for qemu-devel@nongnu.org; Mon, 15 Apr 2013 15:55:56 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:41890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URpVJ-0004P5-Kt for qemu-devel@nongnu.org; Mon, 15 Apr 2013 15:55:53 -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 ; Mon, 15 Apr 2013 15:55:09 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id DEB9138C801A for ; Mon, 15 Apr 2013 15:55:06 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3FJt6aF292558 for ; Mon, 15 Apr 2013 15:55:06 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3FJt6CY024881 for ; Mon, 15 Apr 2013 15:55:06 -0400 Message-ID: <516C5B19.3050603@linux.vnet.ibm.com> Date: Mon, 15 Apr 2013 15:55:05 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <20130411145632.GA2280@redhat.com> <5166F7AE.8070209@linux.vnet.ibm.com> <20130411191533.GA25515@redhat.com> <51671DFF.80904@linux.vnet.ibm.com> <20130412104802.GA23467@redhat.com> <5168105C.5040605@linux.vnet.ibm.com> <20130414082827.GA1548@redhat.com> <516ABDB8.1090100@linux.vnet.ibm.com> <20130414185116.GE7165@redhat.com> <516B06E0.9040804@linux.vnet.ibm.com> <20130414211647.GG7165@redhat.com> <516B538C.5060008@linux.vnet.ibm.com> <516BBB99.5040302@redhat.com> <516BFF83.40505@linux.vnet.ibm.com> <516C00DE.4040700@redhat.com> In-Reply-To: <516C00DE.4040700@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v5: 03/12] comprehensive protocol documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@us.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com On 04/15/2013 09:30 AM, Paolo Bonzini wrote: > Il 15/04/2013 15:24, Michael R. Hines ha scritto: >> Now, in this example, let's say the migration starts up and the hypervisor >> has run out of physical memory and starts swapping during the migration. >> (also for the sake of argument). >> >> The next thing that would immediately happen is the >> next IB verbs function call: "ib_reg_mr()". >> >> This function call would probably fail because there's nothing else left >> to pin and the function call would return an error. >> >> So my question is: Is it not sufficient to send a message back to the >> primary-VM side of the connection which says: >> >> "Your migration cannot proceed anymore, please resume the VM and try >> again somewhere else". >> >> In this case, both the system administrator and the virtual machine are safe, >> nothing has been killed, nothing has crashed, and the management software >> can proceed to make a new management decision. >> >> Is there something wrong with this sequence of events? > I think it's good enough. "info migrate" will then report that > migration failed. > > Paolo > Ok, that's good. So the current patch "[PATCH v2] rdma" is not handling this particular error condition properly, so that's a bug. I'll send out a trivial patch to fix this after the pull along with all the other documentation updates we have discussed. - Michael