lkml.org 
[lkml]   [2012]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/4] KVM: Switch to srcu-less get_dirty_log()
On 03/16/2012 02:55 PM, Takuya Yoshikawa wrote:

> On Fri, 16 Mar 2012 13:03:48 +0800
> Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> 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.
>


Hmm? what can avoid this? Could you please point it out?


>>
>> 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.
>


The problem is the guest page is written before dirty-bitmap is set,
we may log the dirty page in this window like above case...

> 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 way log dirty page in MMU page-table is tricky:

set dirty-bitmap

allow spte to be writeable

page can be written

That means we always set dirty-bitmap _before_ page become dirty that is
the reason why your bitmap-way can work.

> 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.
>


Maybe i'd better firstly understand why "We do not allow this break" :)




\
 
 \ /
  Last update: 2012-03-16 08:33    [W:0.069 / U:15.708 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site