So, basically, the problem seems to be in the way QEMU dirties out the pages after the *bulk* migration of the RAM is done by a calls to `ram_save_iterate`.
The QEMU only dirties pages when there is *miss* to the TLB cache: the code, generated by `tcg_out_tlb_load` called from inside `tcg_out_qemu_st` then calls a `helper_le_st*_mmu` which invalidates the page calling `x86_cpu_handle_mmu_fault` which calls `stl_phys_notdirty`. The last call marks necessary bits in the ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION].
If the memory page changed was looked up in the TLB cache then it is not dirtied. This will mostly happen for the *most used* pages such as structures of the timer interrupt or `delay_tsc` and this is exactly were it happens in our case.
This is the reason for the different pages between source and destination of the migration.
So, basically, the problem seems to be in the way QEMU dirties out the pages after the *bulk* migration of the RAM is done by a calls to `ram_save_iterate`.
The QEMU only dirties pages when there is *miss* to the TLB cache: the code, generated by `tcg_out_tlb_load` called from inside `tcg_out_qemu_st` then calls a `helper_le_st*_mmu` which invalidates the page calling `x86_cpu_ handle_ mmu_fault` which calls `stl_phys_ notdirty` . The last call marks necessary bits in the ram_list. dirty_memory[ DIRTY_MEMORY_ MIGRATION] .
If the memory page changed was looked up in the TLB cache then it is not dirtied. This will mostly happen for the *most used* pages such as structures of the timer interrupt or `delay_tsc` and this is exactly were it happens in our case.
This is the reason for the different pages between source and destination of the migration.