I am writing a Linux kernel module that needs to map a specific physical address to a specific virtual one, and I just can't find a way to do it.
OK, This is my current solution. To map phys_addr to virt_addr I use this code:
page = pfn_to_page(virt_addr >> PAGE_SHIFT);
pte = get_locked_pte(&init_mm, phys_addr, &ptl);
set_pte_at(&init_mm, phys_addr, pte, mk_pte(page, VM_READ | VM_WRITE | VM_EXEC));
spin_unlock(ptl);
flush_tlb_all();
Some explenations: I use the pfn_to_page func to get the page struct corresponding to my virt_addr. I get the page table entry (pte) with the get_locked_pte func which needs the physical address corresponding to the wanted pte and an uninitalized spinlock (ptl). Then, I actually map the page using set_pte_at func and the mk_pte macro, unlock the spinlock and flush the tlb cache.
This solution seems to work pretty well, though it does not survive a context switch.
Could you tell us the kernel version and CPU architecture/type you are using? Generally speaking, if the specific virtual address you want to mapping to does not overlap with kernel virtual address(such as 0xC0000000), and also if the physical address which your device is using does not overlap with system memory physical address range, you can using the low-level functions(if there is not, you can using assemble language to set up MMU TLB entries directly during kernel booting up) to set up MMU TLB entries to map the specific address to a specific virtual one during kernel booting up. I can provide one example based on 2.6.10 kernel version and Freescale PowerPC CPU, there is a function io_block_mapping to do the thing you want.
Related
I understand that the mmu of the processor uses register cr3 to translate linear addresses into physical ones, provided that cr3 is properly set to the physical address of the page directory. But after the kernel has allocated the page tables, how would it find the physical address of the tables and set cr3 to it?
EDIT: I'm talking about the linux kernel.
I'm going to assume that what's bugging you is this: assuming that (once switching to protected mode) the kernel only ever writes to virtual addresses, then this means that it writes the page tables it creates (e.g. for new processes) into virtual addresses. But since the kernel must put a physical address into cr3, then how can it convert the virtual address of the page tables into a physical one?
The short answer is basically what Margaret said: the page tables are found in kernel address space and the kernel keeps a close track of the virtual->physical mapping there.
To flesh this out a little bit more, Linux differentiates between two types of virtual addresses in the kernel:
Kernel virtual addresses - which can map (conceptually) to any physical address; and
Kernel logical addresses - which are virtual addresses that have a linear mapping to physical addresses
The kernel places the page tables in logical addresses, so you only need to focus on those for this discussion.
Mapping a logical address to its corresponding physical one requires only the subtraction of a constant (see e.g. the __pa macro in the Linux source code).
For example, on x86, physical address 0 corresponds to logical address 0xC0000000, and physical address 0x8000 corresponds to logical address 0xC0008000.
So once the kernel places the page tables in a particular logical address, it can easily calculate which physical address it corresponds to.
For further details, you can read the relevant Linux Device Drivers chapter.
On the surface, this appears to be a silly question. Some patience please.. :-)
Am structuring this qs into 2 parts:
Part 1:
I fully understand that platform RAM is mapped into the kernel segment; esp on 64-bit systems this will work well. So each kernel virtual address is indeed just an offset from physical memory (DRAM).
Also, it's my understanding that as Linux is a modern virtual memory OS, (pretty much) all addresses are treated as virtual addresses and must "go" via hardware - the TLB/MMU - at runtime and then get translated by the TLB/MMU via kernel paging tables. Again, easy to understand for user-mode processes.
HOWEVER, what about kernel virtual addresses? For efficiency, would it not be simpler to direct-map these (and an identity mapping is indeed setup from PAGE_OFFSET onwards). But still, at runtime, the kernel virtual address must go via the TLB/MMU and get translated right??? Is this actually the case? Or is kernel virtual addr translation just an offset calculation?? (But how can that be, as we must go via hardware TLB/MMU?). As a simple example, lets consider:
char *kptr = kmalloc(1024, GFP_KERNEL);
Now kptr is a kernel virtual address.
I understand that virt_to_phys() can perform the offset calculation and return the physical DRAM address.
But, here's the Actual Question: it can't be done in this manner via software - that would be pathetically slow! So, back to my earlier point: it would have to be translated via hardware (TLB/MMU).
Is this actually the case??
Part 2:
Okay, lets say this is the case, and we do use paging in the kernel to do this, we must of course setup kernel paging tables; I understand it's rooted at swapper_pg_dir.
(I also understand that vmalloc() unlike kmalloc() is a special case- it's a pure virtual region that gets backed by physical frames only on page fault).
If (in Part 1) we do conclude that kernel virtual address translation is done via kernel paging tables, then how exactly does the kernel paging table (swapper_pg_dir) get "attached" or "mapped" to a user-mode process?? This should happen in the context-switch code? How? Where?
Eg.
On an x86_64, 2 processes A and B are alive, 1 cpu.
A is running, so it's higher-canonical addr
0xFFFF8000 00000000 through 0xFFFFFFFF FFFFFFFF "map" to the kernel segment, and it's lower-canonical addr
0x0 through 0x00007FFF FFFFFFFF map to it's private userspace.
Now, if we context-switch A->B, process B's lower-canonical region is unique But
it must "map" to the same kernel of course!
How exactly does this happen? How do we "auto" refer to the kernel paging table when
in kernel mode? Or is that a wrong statement?
Thanks for your patience, would really appreciate a well thought out answer!
First a bit of background.
This is an area where there is a lot of potential variation between
architectures, however the original poster has indicated he is mainly
interested in x86 and ARM, which share several characteristics:
no hardware segments or similar partitioning of the virtual address space (when used by Linux)
hardware page table walk
multiple page sizes
physically tagged caches (at least on modern ARMs)
So if we restrict ourselves to those systems it keeps things simpler.
Once the MMU is enabled, it is never normally turned off. So all CPU
addresses are virtual, and will be translated to physical addresses
using the MMU. The MMU will first look up the virtual address in the
TLB, and only if it doesn't find it in the TLB will it refer to the
page table - the TLB is a cache of the page table - and so we can
ignore the TLB for this discussion.
The page table
describes the entire virtual 32 or 64 bit address space, and includes
information like:
whether the virtual address is valid
which mode(s) the processor must be in for it to be valid
special attributes for things like memory mapped hardware registers
and the physical address to use
Linux divides the virtual address space into two: the lower portion is
used for user processes, and there is a different virtual to physical
mapping for each process. The upper portion is used for the kernel,
and the mapping is the same even when switching between different user
processes. This keep things simple, as an address is unambiguously in
user or kernel space, the page table doesn't need to be changed when
entering or leaving the kernel, and the kernel can simply dereference
pointers into user space for the
current user process. Typically on 32bit processors the split is 3G
user/1G kernel, although this can vary. Pages for the kernel portion
of the address space will be marked as accessible only when the processor
is in kernel mode to prevent them being accessible to user processes.
The portion of the kernel address space which is identity mapped to RAM
(kernel logical addresses) will be mapped using big pages when possible,
which may allow the page table to be smaller but more importantly
reduces the number of TLB misses.
When the kernel starts it creates a single page table for itself
(swapper_pg_dir) which just describes the kernel portion of the
virtual address space and with no mappings for the user portion of the
address space. Then every time a user process is created a new page
table will be generated for that process, the portion which describes
kernel memory will be the same in each of these page tables. This could be
done by copying all of the relevant portion of swapper_pg_dir, but
because page tables are normally a tree structures, the kernel is
frequently able to graft the portion of the tree which describes the
kernel address space from swapper_pg_dir into the page tables for each
user process by just copying a few entries in the upper layer of the
page table structure. As well as being more efficient in memory (and possibly
cache) usage, it makes it easier to keep the mappings consistent. This
is one of the reasons why the split between kernel and user virtual
address spaces can only occur at certain addresses.
To see how this is done for a particular architecture look at the
implementation of pgd_alloc(). For example ARM
(arch/arm/mm/pgd.c) uses:
pgd_t *pgd_alloc(struct mm_struct *mm)
{
...
init_pgd = pgd_offset_k(0);
memcpy(new_pgd + USER_PTRS_PER_PGD, init_pgd + USER_PTRS_PER_PGD,
(PTRS_PER_PGD - USER_PTRS_PER_PGD) * sizeof(pgd_t));
...
}
or
x86 (arch/x86/mm/pgtable.c) pgd_alloc() calls pgd_ctor():
static void pgd_ctor(struct mm_struct *mm, pgd_t *pgd)
{
/* If the pgd points to a shared pagetable level (either the
ptes in non-PAE, or shared PMD in PAE), then just copy the
references from swapper_pg_dir. */
...
clone_pgd_range(pgd + KERNEL_PGD_BOUNDARY,
swapper_pg_dir + KERNEL_PGD_BOUNDARY,
KERNEL_PGD_PTRS);
...
}
So, back to the original questions:
Part 1: Are kernel virtual addresses really translated by the TLB/MMU?
Yes.
Part 2: How is swapper_pg_dir "attached" to a user mode process.
All page tables (whether swapper_pg_dir or those for user processes)
have the same mappings for the portion used for kernel virtual
addresses. So as the kernel context switches between user processes,
changing the current page table, the mappings for the kernel portion
of the address space remain the same.
The kernel address space is mapped to a section of each process for example on 3:1 mapping after address 0xC0000000. If the user code try to access this address space it will generate a page fault and it is guarded by the kernel.
The kernel address space is divided into 2 parts, the logical address space and the virtual address space. It is defined by the constant VMALLOC_START. The CPU is using the MMU all the time, in user space and in kernel space (can't switch on/off).
The kernel virtual address space is mapped the same way as user space mapping. The logical address space is continuous and it is simple to translate it to physical so it can be done on demand using the MMU fault exception. That is the kernel is trying to access an address, the MMU generate fault , the fault handler map the page using macros __pa , __va and change the CPU pc register back to the previous instruction before the fault happened, now everything is ok. This process is actually platform dependent and in some hardware architectures it mapped the same way as user (because the kernel doesn't use a lot of memory).
In x86 arch, linux kernel 2.6.x, 32bit system
I understand that virtual address 0xC0000000 ~ 0xFFFFFFFF
is reserved for kernel.
and this virtual address can be translated to physical address by
subtracting 0xC0000000.
however, I think even the result is same, MMU will translate
the kernel virtual address(such as 0xC0851000) to physical address by walking through page table.
such as
CR3 -> page directory -> page table -> PFN.
am I correct or wrong?, please correct me if I'm wrong.
I need to develop hardware based kernel monitor in x86, linux 32bit system.
so I need to know this problem
please help.
For kernel logical addresses, you are correct. Kernel virtual addresses, like memory allocated by vmalloc, do not necessarily have a one-to-one mapping to physical addresses that characterize the logical address space, however.
Just bear in mind that kernel logical addresses aren't always translated to physical by subtracting an offset (that's true in x86 but not, say, AVR32).
"and this virtual address can be translated to physical address by
subtracting 0xC0000000"
since page tables for the kernel virtual addresses are configured that way, people have come up with a shortcut you mentioned.
I am working on a small embedded system. When my linux boots up into user space, I know where are my devices in the physical memory. I want to map them into user space virtual addresses. Currently, I am doing it through a kernel module. I use vmalloc/kmalloc (depending on the size) and then I use ioremap_page_range on that returned virtual addresses to map my physical addresses. I dont think that is the correct way to go about. First of all I am allocating memory and then I am asking kernel to remap that virtual address space to some different physical address space. (Initially mapped physical->virtual in vmcall/kmalloc is kinda useless as I dont care about those physical pages. This is definitely not good.)
Instead of this is there a better way to map the known physical memory into user space process. (I know other than my user space process, no one gonna touch that memory.)
Thanks
What you are trying to do is accessing what is called IO memory. I can only encourage you to read the Linux Device Drivers (LDD) book and more specifically the chapter 9.
To "allocate" such an area, you need to call
struct resource *request_mem_region(unsigned long start, unsigned long len, char *name)
. Before your driver can access it, you have to assign it a virtual address, this is done with a call to
void *ioremap(unsigned long phys_addr, unsigned long size)
To ensure that your driver will then work on different architectures/platforms, be sure to use some accessor function to such areas ( ioread8/16/32 or iowrite8/16/32 and all of their variants).
In Kernel module, remap_pfn_range() can be used to convert the physical address to virtual address. The following link will be helpful.
How remap_pfn_range remaps kernel memory to user space?
In Kernel module, remap_pfn_range() can be used to convert the physical address to virtual address. When you don't have a actual devices you can:
1) create a virtual device and,
2) use mmap to those virtual devices to access the very same kernel memory through remap_pfn_range virtual mapping of that process.
3) Usually in dedicated environments you may addition want to pin those physical pages lest they are taken away from your process.
4) You also share these physical addresses with different processes but will need to handle synchronization, independently through other IPC mechanisms as to each process they will look as different addresses.
I am changing the linux kernel scheduler to print the pid of the next process in a known physical memory location. mmap is used for userspace programs while i read that ioremap marks the page as non-cacheable which would slowdown the execution of the program. I would like a fast way to write to a known physical memory. phys_to_virt is the option that i think is feasible. Any idea for a different technique.
PS: i am running this linux kernel on top of qemu. the physical address will be used by qemu to read information sent by guest kernel. writing to a known io-port is not feasible since the device code backing this io-device will be called every time there is an access to the device.
EDIT : I want the physical address location of the pid to be safe. How can I make sure that a physical address that the kernel is using is not being assigned to any process. As far as my knowledge goes, ioremap would mark the page as cacheable and would hence not be of great use.
The simplest way to do this would be to do kmalloc() to get some memory in the kernel. Then you can get the physical address of the pointer that returns by passing it to virt_to_phys(). This is a total hack but for your case of debugging / tracing under qemu, it should work fine.
EDIT: I misunderstood the question. If you want to use a specific physical address, there are a couple of things you could do. Maybe the cleanest thing to do would be to modify the e820 map that qemu passes in to mark the RAM page as reserved, and then the kernel won't use it. (ie the same way that ACPI tables are passed in).
If you don't want to modify qemu, you could also modify the early kernel startup (around arch/x86/kernel/setup.c probably) to do reserve_bootmem() on the specific physical page you want to protect from being used.
To actually use the specified physical address, you can just use ioremap_cache() the same way the ACPI drivers access their tables.
It seems I misunderstood the cache coherency between VM and host part, here is an updated answer.
What you want is "virtual adress in VM" <-> "virtual or physical adress in QEMU adress space".
Then you can either kmalloc it, but it may vary from instance to instance,
or simply declare a global variable in the kernel.
Then virt_to_phys would give you access to the physical address in VM space, and I suppose you can translate this in a QEMU adress space. What do you mean by "a physical address that the kernel is using is not assigned to any process ?" You are afraid the page conatining your variable might be swapped ? kmalloced memory is not swappable
Original (and wrong) answer
If the adress where you want to write is in it's own page, I can't see how an ioremap
of this page would slow down code executing in a different page.
You need a cache flush anyway, and without SSE, I can't see how you can bypass the cache if MMU and cache are on. I can see only this two options :
ioremap and declare a particular page non cacheable
use a "normal" address, and manually do a cache flush each time you write.