From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YumrP-0004b3-Pw for qemu-devel@nongnu.org; Tue, 19 May 2015 15:07:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YumrK-0003Vp-ME for qemu-devel@nongnu.org; Tue, 19 May 2015 15:07:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YumrK-0003VZ-EH for qemu-devel@nongnu.org; Tue, 19 May 2015 15:07:22 -0400 Date: Tue, 19 May 2015 20:07:13 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20150519190712.GK2127@work-vm> References: <1429545445-28216-1-git-send-email-dgilbert@redhat.com> <1429545445-28216-9-git-send-email-dgilbert@redhat.com> <555B85B4.6070903@linux.vnet.ibm.com> <20150519185503.GI2127@work-vm> <555B88CF.90704@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555B88CF.90704@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH 08/10] Rework ram block hash List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael R. Hines" Cc: amit.shah@redhat.com, quintela@redhat.com, arei.gonglei@huawei.com, mrhines@us.ibm.com, qemu-devel@nongnu.org * Michael R. Hines (mrhines@linux.vnet.ibm.com) wrote: > On 05/19/2015 01:55 PM, Dr. David Alan Gilbert wrote: > >>I would like to keep the ramblock list directly addressable by hash > >>on both sides, because, as I mentioned earlier, we want as much > >>flexibility in registering RAMBlock memory as possible by being > >>able to add or delete arbitrary blocks int the list at anytime during > >>a migration. > >> > >>I will try to get the patchset that allows anyone to register memory > >>for transfer out as soon as I can. > >Hmm OK, I think I can rework that to regenerate the hash; it's a little > >difficult without knowing how you're intending to use it. > > > >Dave > > We can use the RAMBlock name as a key to the hash, right? Hmm, OK, I need to look at that; I guess some of those pointers are constant once received. > I see a "future" where storage replication also uses RDMA, > (not that I'm volunteering to write it), but I don't want to > lose the ability for arbitrary QEMU callers to be able to > register/unregister ramblocks dynamically. Yes, I'm going to try and wire RDMA up for COLO like you did for the microcheckpoint work, so I can see the need to keep it more general. Let me go away and think about it; I think I can probably keep the destination side hash, but it was just easier to do it like this since it was unused. If you do have code lieing around that uses it, please post it and cc me and I can try and keep it so it looks like it might work. Dave > - Michae > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK