From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzuPu-0004Tf-DU for qemu-devel@nongnu.org; Tue, 02 Jun 2015 18:12:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzuPn-0006qv-KT for qemu-devel@nongnu.org; Tue, 02 Jun 2015 18:12:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzuPn-0006qo-G2 for qemu-devel@nongnu.org; Tue, 02 Jun 2015 18:12:07 -0400 Message-ID: <556E2A31.9020406@redhat.com> Date: Tue, 02 Jun 2015 18:12:01 -0400 From: John Snow MIME-Version: 1.0 References: <1431531007-10269-1-git-send-email-vsementsov@parallels.com> In-Reply-To: <1431531007-10269-1-git-send-email-vsementsov@parallels.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 00/12] Dirty bitmaps migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: kwolf@redhat.com, peter.maydell@linaro.org, quintela@redhat.com, dgilbert@redhat.com, stefanha@redhat.com, pbonzini@redhat.com, amit.shah@redhat.com, den@openvz.org On 05/13/2015 11:29 AM, Vladimir Sementsov-Ogievskiy wrote: > These patches provide dirty bitmap migration feature. Only named dirty > bitmaps are to be migrated. Migration may be enabled using migration > capabilities. > > v5: > - rebase on master > - drop [PATCH RFC v4 10/13] iotests: add event_wait to VM class > - remove rfc, as incremental backup series by John Snow are in > upstream > > [...] I believe as of now I've reviewed all of these patches. One more respin may be warranted, but I'd like to start pressing for this to be merged into Kevin's tree (iotests, core) or Stefan's (migration). My hunch if Stefan's, since we touch those bits more, and he's already reviewed the core functionality we're modifying, here. It might be nice to have a maintainer review prior to Vladimir respinning the series for my minor nitpicks on v5 so that we can spin up a v6 expecting it to be the final iteration. Vladimir: With this hopefully out of the way soon, would you like to rebase your persistence series now so we can begin picking through that on-list so we can push that through for 2.4? Thanks! --js