On Mon, 2012-06-18 at 15:55 -0500, Seth Jennings wrote:
> This is a continuation of a thread a few months ago:
...
>
> With local_flush_tlb_kernel_range() being a stub,
> the new function local_unmap_kernel_range() is exactly
> the same as unmap_kernel_range() since
> local_flush_tlb_kernel_range() and flush_tlb_kernel_range()
> are both stubs on ppc64.
>
> My knowledge of the ppc64 hashing tlb design is almost
> nothing, but it seems like this should work, albeit slowly
> since it would be a global flush rather than cpu-local.
>
> I was wondering if anyone could tell me why this doesn't work,
> and what needs to be done to make it work.
Hi Seth,
I don't know it that well either, but the way I think it should be
working is:
unmap_kernel_range()
-> vunmap_page_range()
-> vunmap_pud/pmd/pte_range()
-> ptep_get_and_clear()
(arch/powerpc/include/asm/pgtable-ppc64.h)
-> pte_update()
(arch/powerpc/include/asm/pgtable-ppc64.h)
-> hpte_need_flush()
-> flush_hash_page() (because you don't have a batch active
- I assume)
-> pSeries_lpar_hpte_invalidate()
So step one would be to confirm you're getting that far, that would at
least confirm we are doing the invalidate.
cheers
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
