How does shadow page table work during migration?

[Kevin Negy <kevinnegy@xxxxxxxxx>]

Hello,

I'm trying to understand how the shadow page table works in Xen, specifically during live migration. My understanding is that after shadow paging is enabled (sh_enable_log_dirty() in xen/arch/x86/mm/shadow/common.c), a shadow page table is created, which is a complete copy of the current guest page table. Then the CR3 register is switched to use this shadow page table as the active table while the guest page table is stored elsewhere. The guest page table itself (and not the individual entries in the page table) is marked as read only so that any guest memory access that requires the page table will result in a page fault. These page faults happen and are trapped to the Xen hypervisor. Xen will then update the shadow page table to match what the guest sees on its page tables.

Is this understanding correct?

If so, here is where I get confused. During the migration pre-copy phase, each pre-copy iteration reads the dirty bitmap (paging_log_dirty_op() in xen/arch/x86/mm/paging.c) and cleans it. This process seems to destroy all the shadow page tables of the domain with the call to shadow_blow_tables() in sh_clean_dirty_bitmap().

How is the dirty bitmap related to shadow page tables? Why destroy the entire shadow page table if it is the only legitimate page table in CR3 for the domain? 

Thank you,

Kevin