From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkZ7O-000747-CM for qemu-devel@nongnu.org; Thu, 06 Jun 2013 08:16:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UkZ7J-0006VR-CS for qemu-devel@nongnu.org; Thu, 06 Jun 2013 08:16:38 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:60373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkZ7J-0006Uo-4G for qemu-devel@nongnu.org; Thu, 06 Jun 2013 08:16:33 -0400 Date: Thu, 6 Jun 2013 08:16:24 -0400 (EDT) From: Eric Blake Message-ID: <1586032558.12669884.1370520984709.JavaMail.root@redhat.com> In-Reply-To: <1370507765-2806-2-git-send-email-pl@kamp.de> References: <1370507765-2806-1-git-send-email-pl@kamp.de> <1370507765-2806-2-git-send-email-pl@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] Revert "migration: do not sent zero pages in bulk stage" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: aik@ozlabs.ru, pbonzini@redhat.com, qemu-devel@nongnu.org, quintela@redhat.com ----- Original Message ----- > Not sending zero pages breaks migration if a page is zero > at the source but not at the destination. This can e.g. happen > if different BIOS versions are used at source and destination. > It has also been reported that migration on pseries is completely > broken with this patch. > > This reverts commit f1c72795af573b24a7da5eb52375c9aba8a37972. > > +++ b/qapi-schema.json > @@ -499,9 +499,7 @@ > # > # @total: total amount of bytes involved in the migration process > # > -# @duplicate: number of duplicate (zero) pages (since 1.2) > -# > -# @skipped: number of skipped zero pages (since 1.5) > +# @duplicate: number of duplicate pages (since 1.2) > # > # @normal : number of normal pages (since 1.2) > # > @@ -514,8 +512,8 @@ > ## > { 'type': 'MigrationStats', > 'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' , > - 'duplicate': 'int', 'skipped': 'int', 'normal': 'int', > - 'normal-bytes': 'int', 'dirty-pages-rate' : 'int' } } > + 'duplicate': 'int', 'normal': 'int', 'normal-bytes': 'int', > + 'dirty-pages-rate' : 'int' } } This hunk is questionable. Removing something that we have previously sent over the wire may break clients that are expecting this field to exist. Rather than reverting the entire patch, you should consider keeping this field present in QMP, even if you now always populate it with 0. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org