Hi Andrea, I'm wondering if this bug is the opposite way around from what I originally thought it was - I don't think the problem is 0 pages on the destination; I think it's more subtle.
I added some debug to print the source VMs memory and also the byte in the destination's 1st page (this is in the nest): nhp_range: block: pc.ram @ 0x7fc59a800000 Destination 1st byte: e8,df <stop> df OK, so that tells us that the destination is running OK, and that it stops running when we tell it to. Memory content inconsistency at f79000 first_byte = df last_byte = de current = 9 hit_edge = 1 src_byte = 9 'src_byte' is saying that the source VM had the byte 9 in that page (we've still got the source VMs memory - it's paused at this point in the test) so adding the start of pc.ram we get that being a host address of 0x7FC59B779000 and in the logs I see: postcopy_place_page: 0x55ba64503f7d->0x7fc59b779000 copy=4096 1stbyte=9/9 OK, so that shows that when the destination received the page it was also '9' and after the uffdio_copy it read as 9 - so the page made it into RAM; it wasn't 0. But that also means, that page hasn't changed *after* migration; why not? We can see that the other pages are changing (that Destination 1st byte line shows the 1st byte of the test memory changed) - so the incrementer loop has apparently incremented every byte of the test memory multiple times - except these pages are still stuck at the '9' it got when we placed the page into it atomically. I've been unable to trigger this bug in a standalone test case that ran without kvm. Is it possible that the guest KVM CPU isn't noticing some change to the mapping? Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
