On 06.06.2013 14:16, Eric Blake wrote:
----- 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.
You are right. I might still account zero pages in the bulk phase to give this
field a meaning. These pages are very likely not written on the destination
except
for the cornercases. What do you think?
Peter
