Xen devel - Jul 2012 - About log dirty mode during migration

Hi All,
I have several questions about  log dirty mode during live migration. 
For my understanding, each time after XEN_DOMCTL_SHADOW_OP_CLEAN or
XEN_DOMCTL_SHADOW_OP_PEEK operation, all the pages are set as read only. The
following memory accesses to the memory pages will cause page fault (permission
conflict) then using page_mark_dirty function to set the dirty bitmap.
However, after I read the codes, I can''t find the code places for the
above operations:
a. Where is the exact place for the domain to set all the memory pages as read
only? From paging_log_dirty_op function, I can see that when the operation is
XEN_DOMCTL_SHADOW_OP_CLEAN, it will call clear_page. But what is the function of
this one? Why doesn''t  it do for XEN_DOMCTL_SHADOW_OP_PEEK?
b. Where is the exact place for the domain to trap into hypervisor because of
permission conflict and then set the memory pages are RW?
I really can''t find the places in the code. Thanks for your help. 

Best,
Ming

Hello,

At 21:57 -0400 on 18 Jul (1342648675), lmingcsce wrote:
> For my understanding, each time after XEN_DOMCTL_SHADOW_OP_CLEAN or
> XEN_DOMCTL_SHADOW_OP_PEEK operation, all the pages are set as read
> only. The following memory accesses to the memory pages will cause
> page fault (permission conflict) then using page_mark_dirty function
> to set the dirty bitmap.
That''s about right, yes.
> However, after I read the codes, I can''t find the code places for
the above operations:
> a. Where is the exact place for the domain to set all the memory pages
> as read only?
For HAP (EPT/NPT) guests, hap_clean_dirty_bitmap() 
calls p2m_change_entry_type_global() to set all memory to type
p2m_ram_logdirty, which is read-only.

For shadow-pagetable guests, shadow_clean_dirty_bitmap() calls
shadow_blow_tables(), which actually discards _all_ the guest''t memory
mappings.  When they are rebuilt in the pagefault handler,
_sh_propagate() either makes them read-only or calls
paging_mark_dirty().
> From paging_log_dirty_op function, I can see that when
> the operation is XEN_DOMCTL_SHADOW_OP_CLEAN, it will call
> clear_page. But what is the function of this one? 
It zeroes a page of memory.  In this case, the page is part of the
bitmap where dirty pages are recorded. 
> Why doesn''t it do for XEN_DOMCTL_SHADOW_OP_PEEK?
This is described in the public header files:

 /* Log-dirty bitmap operations. */
  /* Return the bitmap and clean internal copy for next round. */
 #define XEN_DOMCTL_SHADOW_OP_CLEAN       11
  /* Return the bitmap but do not modify internal copy. */
 #define XEN_DOMCTL_SHADOW_OP_PEEK        12
> b. Where is the exact place for the domain to trap into hypervisor
> because of permission conflict and then set the memory pages are RW?
For HAP, this is handled from the nested-pagefault handler, in
hvm_hap_nested_page_fault(), which calls paging_mark_dirty and sets the
page''s type back to p2m_ram_rw.

For shadowed guests, the normal pagefault path calls sh_page_fault(),
which eventually calls down to _sh_propagate as I described above. 

Cheers,

Tim.