Re: [Xen-devel] About log dirty mode during migration

[Tim Deegan <tim@xxxxxxx>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel