Lines Matching +full:user +full:- +full:visible
19 if it can be proven that a user address space has never executed
25 virtual-->physical address translations obtained from the software
36 visible to the cpu.
43 This interface flushes an entire user address space from
46 'mm' will be visible to the cpu. That is, after running,
56 Here we are flushing a specific range of (user) virtual
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'.
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,
126 a virtual-->physical translation to exist for a virtual address
133 indexed caches which must be flushed when virtual-->physical
143 This interface flushes an entire user address space from
152 This interface flushes an entire user address space from
165 Here we are flushing a specific range of (user) virtual
167 entries in the cache for 'vma->vm_mm' for virtual addresses in
168 the range 'start' to 'end-1'.
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
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
237 size). This setting will force the SYSv IPC layer to only allow user
246 Next, you have to solve the D-cache aliasing issue for all
248 mapped into some user address space, there is always at least one more
250 PAGE_OFFSET. So immediately, once the first user maps a given
251 physical page into its address space, by implication the D-cache
258 These two routines store data in user anonymous or COW
259 pages. It allows a port to efficiently avoid D-cache alias
266 of the same "color" as the user mapping of the page. Sparc64
270 user will ultimately have this page mapped, and the 'page'
273 If D-cache aliasing is not an issue, these two routines may
282 b) the kernel is about to read from a page cache page and user space
285 on any page found in the user address space and thus driver
292 space of a user process. So for example, VFS layer code
299 flush here to handle D-cache aliasing, to make sure these kernel stores
300 are visible to user space mappings of that page.
304 reads of these pages will see the most recent stores done by the user.
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
340 of arbitrary user pages (f.e. for ptrace()) it will use
377 subsystem assumes that the user mapping and kernel offset mapping are
387 modified in the vmap range is made visible to the physical