pcmcia: pcmcia_config_loop() ConfigIndex unification
[linux-2.6.git] / Documentation / cachetlb.txt
index e132fb1..da42ab4 100644 (file)
@@ -49,9 +49,6 @@ changes occur:
        page table operations such as what happens during
        fork, and exec.
 
-       Platform developers note that generic code will always
-       invoke this interface without mm->page_table_lock held.
-
 3) void flush_tlb_range(struct vm_area_struct *vma,
                        unsigned long start, unsigned long end)
 
@@ -72,9 +69,6 @@ changes occur:
        call flush_tlb_page (see below) for each entry which may be
        modified.
 
-       Platform developers note that generic code will always
-       invoke this interface with mm->page_table_lock held.
-
 4) void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)
 
        This time we need to remove the PAGE_SIZE sized translation
@@ -93,33 +87,7 @@ changes occur:
 
        This is used primarily during fault processing.
 
-       Platform developers note that generic code will always
-       invoke this interface with mm->page_table_lock held.
-
-5) void flush_tlb_pgtables(struct mm_struct *mm,
-                          unsigned long start, unsigned long end)
-
-   The software page tables for address space 'mm' for virtual
-   addresses in the range 'start' to 'end-1' are being torn down.
-
-   Some platforms cache the lowest level of the software page tables
-   in a linear virtually mapped array, to make TLB miss processing
-   more efficient.  On such platforms, since the TLB is caching the
-   software page table structure, it needs to be flushed when parts
-   of the software page table tree are unlinked/freed.
-
-   Sparc64 is one example of a platform which does this.
-
-   Usually, when munmap()'ing an area of user virtual address
-   space, the kernel leaves the page table parts around and just
-   marks the individual pte's as invalid.  However, if very large
-   portions of the address space are unmapped, the kernel frees up
-   those portions of the software page tables to prevent potential
-   excessive kernel memory usage caused by erratic mmap/mmunmap
-   sequences.  It is at these times that flush_tlb_pgtables will
-   be invoked.
-
-6) void update_mmu_cache(struct vm_area_struct *vma,
+5) void update_mmu_cache(struct vm_area_struct *vma,
                         unsigned long address, pte_t pte)
 
        At the end of every page fault, this routine is invoked to
@@ -132,7 +100,7 @@ changes occur:
        translations for software managed TLB configurations.
        The sparc64 port currently does this.
 
-7) void tlb_migrate_finish(struct mm_struct *mm)
+6) void tlb_migrate_finish(struct mm_struct *mm)
 
        This interface is called at the end of an explicit
        process migration. This interface provides a hook
@@ -142,12 +110,6 @@ changes occur:
        The ia64 sn2 platform is one example of a platform
        that uses this interface.
 
-8) void lazy_mmu_prot_update(pte_t pte)
-       This interface is called whenever the protection on
-       any user PTEs change.  This interface provides a notification
-       to architecture specific code to take appropiate action.
-
-
 Next, we have the cache flushing interfaces.  In general, when Linux
 is changing an existing virtual-->physical mapping to a new value,
 the sequence will be in one of the following forms:
@@ -188,10 +150,21 @@ Here are the routines, one by one:
        lines associated with 'mm'.
 
        This interface is used to handle whole address space
-       page table operations such as what happens during
-       fork, exit, and exec.
+       page table operations such as what happens during exit and exec.
 
-2) void flush_cache_range(struct vm_area_struct *vma,
+2) void flush_cache_dup_mm(struct mm_struct *mm)
+
+       This interface flushes an entire user address space from
+       the caches.  That is, after running, there will be no cache
+       lines associated with 'mm'.
+
+       This interface is used to handle whole address space
+       page table operations such as what happens during fork.
+
+       This option is separate from flush_cache_mm to allow some
+       optimizations for VIPT caches.
+
+3) void flush_cache_range(struct vm_area_struct *vma,
                          unsigned long start, unsigned long end)
 
        Here we are flushing a specific range of (user) virtual
@@ -208,7 +181,7 @@ Here are the routines, one by one:
        call flush_cache_page (see below) for each entry which may be
        modified.
 
-3) void flush_cache_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn)
+4) void flush_cache_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn)
 
        This time we need to remove a PAGE_SIZE sized range
        from the cache.  The 'vma' is the backing structure used by
@@ -229,7 +202,7 @@ Here are the routines, one by one:
 
        This is used primarily during fault processing.
 
-4) void flush_cache_kmaps(void)
+5) void flush_cache_kmaps(void)
 
        This routine need only be implemented if the platform utilizes
        highmem.  It will be called right before all of the kmaps
@@ -241,7 +214,7 @@ Here are the routines, one by one:
 
        This routing should be implemented in asm/highmem.h
 
-5) void flush_cache_vmap(unsigned long start, unsigned long end)
+6) void flush_cache_vmap(unsigned long start, unsigned long end)
    void flush_cache_vunmap(unsigned long start, unsigned long end)
 
        Here in these two interfaces we are flushing a specific range
@@ -251,7 +224,7 @@ Here are the routines, one by one:
 
        The first of these two routines is invoked after map_vm_area()
        has installed the page table entries.  The second is invoked
-       before unmap_vm_area() deletes the page table entries.
+       before unmap_kernel_range() deletes the page table entries.
 
 There exists another whole class of cpu cache issues which currently
 require a whole different set of interfaces to handle properly.
@@ -371,6 +344,28 @@ maps this page at its virtual address.
        likely that you will need to flush the instruction cache
        for copy_to_user_page().
 
+  void flush_anon_page(struct vm_area_struct *vma, struct page *page,
+                       unsigned long vmaddr)
+       When the kernel needs to access the contents of an anonymous
+       page, it calls this function (currently only
+       get_user_pages()).  Note: flush_dcache_page() deliberately
+       doesn't work for an anonymous page.  The default
+       implementation is a nop (and should remain so for all coherent
+       architectures).  For incoherent architectures, it should flush
+       the cache of the page at vmaddr.
+
+  void flush_kernel_dcache_page(struct page *page)
+       When the kernel needs to modify a user page is has obtained
+       with kmap, it calls this function after all modifications are
+       complete (but before kunmapping it) to bring the underlying
+       page up to date.  It is assumed here that the user has no
+       incoherent cached copies (i.e. the original page was obtained
+       from a mechanism like get_user_pages()).  The default
+       implementation is a nop and should remain so on all coherent
+       architectures.  On incoherent architectures, this should flush
+       the kernel cache for page (using page_address(page)).
+
+
   void flush_icache_range(unsigned long start, unsigned long end)
        When the kernel stores into addresses that it will execute
        out of (eg when loading modules), this function is called.