Documentation/core-api/cachetlb.rst

25 virtual-->physical address translations obtained from the software
59 	modifications for the address space 'vma->vm_mm' in the range
60 	'start' to 'end-1' will be visible to the cpu.  That is, after
62 	virtual addresses in the range 'start' to 'end-1'.
67 	The interface is provided in hopes that the port can find
78 	address space is available via vma->vm_mm.  Also, one may
79 	test (vma->vm_flags & VM_EXEC) to see if this region is
81 	split-tlb type setups).
84 	page table modification for address space 'vma->vm_mm' for
87 	'vma->vm_mm' for virtual address 'addr'.
97 	in the software page tables for address space "vma->vm_mm"
103 	A port may use this information in any way it so chooses.
104 	For example, it could use this event to pre-load TLB
106 	The sparc64 port currently does this.
109 is changing an existing virtual-->physical mapping to a new value,
126 a virtual-->physical translation to exist for a virtual address
133 indexed caches which must be flushed when virtual-->physical
167 	entries in the cache for 'vma->vm_mm' for virtual addresses in
168 	the range 'start' to 'end-1'.
173 	The interface is provided in hopes that the port can find
184 	address space is available via vma->vm_mm.  Also, one may
185 	test (vma->vm_flags & VM_EXEC) to see if this region is
191 	translates to.  It is this mapping which should be removed from
195 	'vma->vm_mm' for virtual address 'addr' which translates
218 	space for virtual addresses in the range 'start' to 'end-1'.
229 Is your port susceptible to virtual aliasing in its D-cache?
230 Well, if your D-cache is virtually indexed, is larger in size than
234 If your D-cache has this problem, first define asm/shmparam.h SHMLBA
236 addressed D-cache (or if the size is variable, the largest possible
243   This does not fix shared mmaps, check out the sparc64 port for
246 Next, you have to solve the D-cache aliasing issue for all
249 mapping, that of the kernel in its linear mapping starting at
251 physical page into its address space, by implication the D-cache
259 	pages.  It allows a port to efficiently avoid D-cache alias
262 	For example, a port may temporarily map 'from' and 'to' to
266 	of the same "color" as the user mapping of the page.  Sparc64
273 	If D-cache aliasing is not an issue, these two routines may
298 	page at the kernel virtual mapping of that page.  It is important to
299 	flush here to handle D-cache aliasing, to make sure these kernel stores
306 	If D-cache aliasing is not an issue, this routine may simply be defined
309         There is a bit set aside in folio->flags (PG_arch_1) as "architecture
315 	actual flush if there are currently no user processes mapping this
320 	folio_flush_mapping() returns a mapping, and mapping_mapped() on that
321 	mapping returns %false, just mark the architecture private page
377 subsystem assumes that the user mapping and kernel offset mapping are