[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] About log dirty mode during migration
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |