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.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
