From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIKl2-0002ra-HR for qemu-devel@nongnu.org; Wed, 20 Mar 2013 11:16:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIKkw-0000f5-9F for qemu-devel@nongnu.org; Wed, 20 Mar 2013 11:16:52 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:35144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIKkw-0000em-5a for qemu-devel@nongnu.org; Wed, 20 Mar 2013 11:16:46 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Mar 2013 11:16:42 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 376E06E8099 for ; Wed, 20 Mar 2013 11:16:31 -0400 (EDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2KFGHoO25362552 for ; Wed, 20 Mar 2013 11:16:18 -0400 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 r2KFGBha020648 for ; Wed, 20 Mar 2013 09:16:11 -0600 Message-ID: <5149D2A4.2070106@linux.vnet.ibm.com> Date: Wed, 20 Mar 2013 11:15:48 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <5147A209.80202@linux.vnet.ibm.com> <20130319081939.GC11259@redhat.com> <51487F68.2060305@linux.vnet.ibm.com> <20130319151606.GA13649@redhat.com> <51488521.4010909@linux.vnet.ibm.com> <20130319153658.GA14317@redhat.com> <51489BC3.3030504@linux.vnet.ibm.com> <51489D05.2000400@redhat.com> <5148A2F6.1070206@linux.vnet.ibm.com> <5148A5FB.1000209@redhat.com> <20130320130754.GA9777@redhat.com> In-Reply-To: <20130320130754.GA9777@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, Paolo Bonzini OK, can we make a deal? =) I'm willing to put in the work to perform the dynamic registration on the destination side, but let's go a step further and piggy-back on the effort: We need to couple this registration with a very small modification to save_ram_block(): Currently, save_ram_block does: 1. is RDMA turned on? if yes, unconditionally add to next chunk (will be made to dynamically register on destination) 2. is_dup_page() ? if yes, skip 3. in xbzrle cache? if yes, skip 4. still not sent? if yes, transmit I propose adding a "stub" function that adds: 0. is page mapped? if yes, skip (always returns true for now) 1. same 2. same 3. same 4. same Then, later, in a separate patch, I can implement /dev/pagemap support. When that's done, RDMA dynamic registration will actually take effect and benefit from actually verifying that the page is mapped or not. - Michael On 03/20/2013 09:07 AM, Michael S. Tsirkin wrote: > My problem is with the protocol. If it assumes at the protocol level > that everything is pinned down on the destination, we'll have to > rework it all to make it really useful.