Lines Matching +full:data +full:- +full:addr

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'.
73 4) ``void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)``
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
85 	user virtual address 'addr' will be visible to the cpu.  That
87 	'vma->vm_mm' for virtual address 'addr'.
97 	in the software page tables for address space "vma->vm_mm"
104 	For example, it could use this event to pre-load TLB
109 is changing an existing virtual-->physical mapping to a new value,
120 	3) flush_cache_page(vma, addr, pfn);
122 	   flush_tlb_page(vma, addr);
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'.
179 4) ``void flush_cache_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn)``
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
190 	left by PAGE_SHIFT to get the physical address) that 'addr'
195 	'vma->vm_mm' for virtual address 'addr' which translates
218 	space for virtual addresses in the range 'start' to 'end-1'.
226 The biggest problem is that of virtual aliasing in the data cache
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
246 Next, you have to solve the D-cache aliasing issue for all
251 physical page into its address space, by implication the D-cache
255   ``void copy_user_page(void *to, void *from, unsigned long addr, struct page *page)``
256   ``void clear_user_page(void *to, unsigned long addr, struct page *page)``
258 	These two routines store data in user anonymous or COW
259 	pages.  It allows a port to efficiently avoid D-cache alias
269 	The 'addr' parameter tells the virtual address where the
273 	If D-cache aliasing is not an issue, these two routines may
297 	that the kernel executes store instructions that dirty data in that
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
339 	When the kernel needs to copy arbitrary data in and out
386        the vmap area.  This is to make sure that any data the kernel
396        speculatively reading data while the I/O was occurring to the
397        physical pages.  This is only necessary for data reads into the