Re: CPU-local TLB flushing

[Michael Ellerman <michael@ellerman.id.au>]

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