[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120316155511.70455b4a.yoshikawa.takuya@oss.ntt.co.jp>
Date: Fri, 16 Mar 2012 15:55:11 +0900
From: Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp>
To: Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
Cc: avi@...hat.com, mtosatti@...hat.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] KVM: Switch to srcu-less get_dirty_log()
On Fri, 16 Mar 2012 13:03:48 +0800
Xiao Guangrong <xiaoguangrong@...ux.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.
>
> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists