On Fri, Feb 12, 2016 at 03:54:18PM +1100, Alexey Kardashevskiy wrote: > On 02/11/2016 04:32 PM, Paul Mackerras wrote: > >On Thu, Jan 21, 2016 at 06:39:37PM +1100, Alexey Kardashevskiy wrote: > >>+ rmap = (void *) vmalloc_to_phys(rmap); > >>+ > >>+ lock_rmap(rmap); > > > >A comment here explaining why we lock the rmap and what that achieves > >would be useful for future generations. > > > /* This protects the guest page with the TCE list from going away while we > are reading TCE list */ > > ? > > By "going away" I mean H_ENTER/H_REMOVE executed on parallel CPUs, is this > roughly correct? as I did grep for "lock_rmap()" and did not find a single > comment next to it... Actually, taking the rmap lock stops the guest real -> host real mapping from changing. For the comment, I suggest this: /* * Synchronize with the MMU notifier callbacks in * book3s_64_mmu_hv.c (kvm_unmap_hva_hv etc.). * While we have the rmap lock, code running on other CPUs * cannot finish unmapping the host real page that backs * this guest real page, so we are OK to access the host * real page. */ Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
