vsyscall: kernel maps these system calls implementation and the related-data into user space pages.
So why vsyscall's address range is 0xffffffffff600000-0xffffffffff601000 (kernel space)?
Related
I am working on a solution similar to user-space input/output drivers(Linux kernel UIO).
Linux kernel UIO
I intend to map a specific physical address range(starting at specific physical address) from kernel space to user-space of size 0x100, which is less than one page size(4 Kb). I tried to solve this via kernel UIO framework but it maps(via mmap file operation of file /dev/uio) minimum for one page. I want a solution so that I can map exact specific 0x100 physical memory to user-space. If the user-space tries to access beyond that 0x100 range, it should not be allowed. So far the solution I came across deal in page level mappings.
what is kernel mapping? What are permanent mapping and temporary mapping. What is a window in this context? I went through code and explanation of this but could not understand this
I'm assuming you're talking about memory mapping in linux kernel.
Memory mapping is a process of mapping kernel address space directly to users process's address space.
Types of addresses :
User virtual address : These are the regular addresses seen by user-space programs
Physical addresses : The addresses used between the processor and the system’s memory.
Bus addresses : The addresses used between peripheral buses and memory. Often, they are the same as the physical addresses used by the processor, but that is not necessarily the case.
Kernel logical addresses : These make up the normal address space of the kernel.
Kernel virtual addresses : Kernel virtual addresses are similar to logical addresses in that they are a mapping from a kernel-space address to a physical address.
High and Low Memory :
Low memory : Memory for which logical addresses exist in kernel space. On almost every system you will likely encounter, all memory is low memory.
High memory : Memory for which logical addresses do not exist, because it is beyond the address range set aside for kernel virtual addresses.This means the kernel needs to start using temporary mappings of the pieces of physical memory that it wants to access.
Kernel splits virtual address into two part user address space and kernel address space. The kernel’s code and data structures must fit into that space, but the biggest consumer of kernel address space is virtual mappings for physical memory. Thus kernel needs its own virtual address for any memory it must touch directly. So, the maximum amount of physical memory that could be handled by the kernel was the amount that could be mapped into the kernel’s portion of the virtual address space, minus the space used by kernel code.
Temporary mapping : When a mapping must be created but the current context cannot sleep, the kernel provides temporary mappings (also called atomic mappings). The kernel can atomically map a high memory page into one of the reserved mappings (which can hold temporary mappings). Consequently, a temporary mapping can be used in places that cannot sleep, such as interrupt handlers, because obtaining the mapping never blocks.
Ref :
kernel.org/doc/Documentation/vm/highmem.txt
static.lwn.net/images/pdf/LDD3/ch15.pdf
man mmap
notes.shichao.io/lkd/ch12/
A full answer would be very long, for details refers (for example) to Linux Kernel Addressing or Understanding the Linux Kernel (pages 306-). These concepts are related to the way address spaces are organized in Linux. Firstly how kernel space is mapped into user space (kernel mapped onto user space simplifies the switching in between user and kernel mode) and, secondly the way physical memory is mapped onto kernel space (because kernel have to manage physical memory).
Beware that this is of no concern in modern 64bit architectures.
Some of the points mentioned in the Linux kernel Development (by Robert
Love) book about mm_struct and kernel thread are :
"Kernel threads do not have a process address space and therefore do not
have an associated memory descriptor. Thus, the mm field of a kernel
thread's process descriptor is NULL. "
"Because kernel threads do not have any pages in user-space, they do not
really deserve their own memory descriptor and page tables (page tables are
discussed later in the chapter). Despite this, kernel threads need some of
the data, such as the page tables, even to access kernel memory."
"Kernel threads do not have an address space and mm is NULL. Therefore, when
a kernel thread is scheduled, the kernel notices that mm is NULL and keeps
the previous process's address space loaded. The kernel then updates the
active_mm field of the kernel thread's process descriptor to refer to the
previous process's memory descriptor. The kernel thread can then use the
previous process's page tables as needed."
Now my queries are:
1. First it is mentioned that the kernel threads dont have any page in user
space and hence they dont deserve memory desriptor and page tables and in
the next line it says it needs some data such as page tables to access
kernel memory. What page table it is referring here?? Every process has its
own page table for mapping the virtual to physical address, why kernel
thread requires that?
How page table use by kernel thread?
Every thread whether its a user-space or kernel space process requires a page-table. The kernel address space (Virtual Memory address space) is directly mapped to the physical address space where as the user-space address space isn't directly mapped. Moreover the user-space application address space mappings keeps changing as the new processes are created, terminated, swapped whereas the kernel space mappings remain constant.
To learn more you can visit the following link :-
Process address Space
Or post the queries here.
There are some usespace applications and kernel threads in your system. Every virtual address space consists of kernel and user part. Kernel is the same for all processes, user part is different.
Every process has its own page table for mapping the virtual to
physical address, why kernel thread requires that?
Kernel threads need page tables to make translation from virtual address to physical while accessing memory.
How page table use by kernel thread?
Imagine a simple case, memory write such as a[i] = 5; in kernel space. This one typically goes through MMU, which use page tables to get physical address according to virtual address (in this case &a[i]). So there is no something special about kernel threads, the difference is that on context switch they don't change pgd (page global directory), they use pgd of last process, because all processes have the same kernel part and you can pick just last one (see actime_mm) and it will be ok.
Ioremap is done in kernel mode.
Does ioremap create an entry in pagetables during
the call of ioremap or when the address is accessed ?
For ioremap, the page tables are updated immediately. Since the function is intended to map physical "I/O" addresses into kernel virtual address space, there would be no point in setting up page table entries to cause a page fault. In essence, a page fault supports the dynamic substitution of one page of physical memory for another. But by definition, I/O space is not substitutable.
For example, one common use of ioremap is to allow a kernel module to access register space on an add-on card or other peripheral. In order to perform operations on the card, the kernel code must obtain a virtual address that refers to the physical bus address corresponding to the card's register area. ioremap causes the allocation of virtual space, and the establishment of a mapping from that virtual range to the card space. It wouldn't make sense to "swap" the underlying physical page: that page isn't a real memory page, it has special functions that can't be duplicated by any other physical memory.
get_user_pages() implementation shows that it uses virt_to_page() to extract struct page pointer for given user space, page aligned virtual address.
http://lxr.free-electrons.com/source/mm/nommu.c#L171
virt_to_page() can only be used for directly mapped kernel addresses. How's that get_user_pages() is using the same for user space pages ?
You are looking at nommu.c, which is the implementation for hardware that does not have virtual memory. On those machines, there are no mappings.
The real implementation in memory.c uses the appropriate accesses for user-space pages.