On Fri, 16 Mar 2012 13:03:48 +0800 Xiao Guangrong <xiaoguangrong@xxxxxxxxxxxxxxxxxx> wrote: > For my quickly review, mmu_lock can not protect everything, if the guest page Yes and ... > is written out of the shadow page/ept table, dirty page will be lost. No. > > There is a example: > > CPU A CPU B > guest page is written by write-emulation > > hold mmu-lock and see dirty-bitmap > is not be changed, then migration is > completed. We do not allow this break. > > call mark_page_dirty() to set dirty_bit map > > > Right? As you pointed out, we cannot assume mutual exclusion by mmu_lock. That is why we are using atomic bitmap operations: xchg and set_bit. In this sense we are at least guaranteed to get the dirty page information in dirty_bitmap - the current one or next one. So what we should care about is to not miss the information written in the next bitmap at the time we actually migrate the guest. Actually the userspace stops the guest at the final stage and then send the remaining pages found in the bitmap. So the above break between write and mark_page_dirty() cannot happen IIUC. Thanks, Takuya -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
