On Sat, Dec 24, 2011 at 11:52:51AM +0900, Takuya Yoshikawa wrote: > On Fri, 23 Dec 2011 09:14:51 -0200 > Marcelo Tosatti <[email protected]> wrote: > > > > >btw mark_page_dirty() itself seems to assume mmu_lock protection that > > > >doesn't exist. Marcelo? > > > > > > > > Not mmu_lock protection, kvm->srcu protection. > > But it just protects slot readers against updates and two, or more, threads > can call mark_page_dirty() concurrently?
Yes, two or more threads can call mark_page_dirty() concurrently. > What I am worring about here is the atomicity of bitmap updates. > > commit c8240bd6f0b4b1b21ffd36dd44114d05c7afe0c0 > Author: Alexander Graf <[email protected]> > Date: Fri Oct 30 05:47:26 2009 +0000 > > Use Little Endian for Dirty Bitmap > > has changed set_bit() to the non-atomic version and nothing protects > dirty bits if mmu_lock is not held. > > The changelog has no explanation why using non-atomic version is safe. > Some comment in the code may be worthwhile if it is really safe. It should not be necessary, atomicity of updates to memslot->dirty_bitmap, because of RCU updates to the memslot pointer (note memslot = gfn_to_memslot(kvm, gfn); in mark_page_dirty). The order is: - update page data. - grab memslot pointer. - set page bit in memslot. > I want to see some clear reasoning now if possible. The reasoning is stated above, but reviewing the code to make sure its correct is not a bad idea. > Takuya > > > > > > I want to hear the answer for this question. > > > > > > Though I myself is reading the code, I cannot understand it thoroughly > > > yet. > > > I wish if there were mmu_lock entry in locking.txt ... > > > > Agreed. > > > > -- > Takuya Yoshikawa <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
