In the virtual memory concept- each process maintains their own page table. This page table maps the virtual address to the kernel virtual address. This kernel virtual address translates the address to Physical RAM. I understand that there is a Kernel Virtual adddres - vm area struct. This vm area struct finally maps this address to the Physical address. When I do cat /proc//maps - I see the direct mapping of virtual address to physical address. Because it maps the address to the file - with inode. So, it looks that it is the address on the hard-disk, file descriptor, major-minor number. There are a few address that are on the RAM. So, I can say that I can't see the table where the Virtual address is mapped to Kernel virtual address. I want to see that table. How can I see that? It should not be in the kernel space. Because when process is accessing let's say memory - 0x1681010 then this should be translated to kernel virtual memory address. Finally, this address should be translated to physical memory address.
1 Answers
No, the Linux kernel maintains the processes page tables (but not the processes themselves). Processes are only seeing virtual memory thorough their address space. Processes use some syscalls, like e.g. mmap(2) or execve(2), to change their address space.
Physical addresses and page tables and dealing with and managing the MMU is the business of the kernel, which actually provides some "abstract machine" (with the virtual address spaces, the syscalls as atomic elementary operations, etc...) to user applications. The applications don't see the raw (x86) hardware, but only the user mode as given by the kernel. Some hardware resources and instructions are not available to them (they only run in user space).
The page tables are managed by the kernel, and indeed various processes may use different -or sometimes same- page tables. (So context switches managed by the kernl may need to reconfigure the MMU). You don't care, (and the user processes don't see page tables) the kernel will manage them.
And no, /proc/self/maps does not show anything about physical addresses, only about virtual one. The kernel is permitted to move processes from one core to another, to move pages from one physical (not virtual) address to another, etc...., at any time; and applications usually don't see this (they might query this with mincore(2), getcpu(2) and thru proc(5) ...)
Applications should not care about physical memory or interrupts, like page faults (only the kernel care about these; sometimes by sending signals).
The virtual to physical address translation happens in the MMU. Usually, it is successful (perhaps transparently accessing page tables), and the processor sends on the bus to the RAM the translated physical address (corresponding to some virtual address handled by the user-mode machine instruction). When the MMU cannot handle it, a page fault occurs, which is processed by the kernel (which could swap-in some page, send a SIGSEGV, do a context switch, etc...)
See also the processor architecture, instruction set, page table, paging, translation lookaside buffer, cache, x86 and x86-64 wikipages (and follow all the links I gave you).
/proc/mapsonly tell you the regions of virtual address space that your process has been given. - Kerrek SB