Re: CPU-local TLB flushing

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