虚拟地址物理地址linux
虚拟地址物理地址linux
?学习啦小编整理了linux环境下虚拟地址物理地址的相关资料。供大家参考!
虚拟地址物理地址linux
内核从3G开始的那一段是连续映射
而且这种固定映射最大到896M的地址范围,也即从0xc0000000-0xf7ffffff的虚拟地址采用固定映射,称为内核逻辑地址.剩下的1G-896=128M范围的虚拟地址可以映射到任意物理地址.称为内核虚拟地址.当实际内存大于1G时(实际上是> 896M时),用这块地址空间做映射.
实际的计算机体系结构有硬件的制约，这限制了页框可以使用的方式。尤其是，Linux内核必须处理80x86体系结构的两种硬件约束：
ISA总线的直接存储器(DMA)处理器有一个严格的限制：它们只能对RAM的前16MB寻址。
在具有大容量RAM的现代32位计算机中，CPU不能直接访问所有的物理存储器，因为线形地址空间太小。
为了应付这两种限制，Linux把物理存储器划分为三个管理区(zone)：
ZONE_DMA：包含低于16MB的存储器页
ZONE_NORMAL：包含高于16MB且低于896MB的存储器页
ZONE_HIGHMEM：包含高于896MB的存储器页
ZONE_DMA区包含的页可以由老式基于ISA的设备通过DMA使用。
ZONE_DMA和ZONE_NORMAL和区包含的存储器的“常规”页，通过把它们线性地映射到线性地址空间的第4个GB，内核就可以直接进行访问。相反，包含的存储器页不能由内核直接访问，但它们也线性映射到了线性地址空间的第4个GB。在64位体系结构上没有使用在64位体系结构上没有使用ZONE_NORMAL。
这里只分析分配连续物理地址的函数。对于 vmalloc() 这种分配非连续物理地址的函数不在本记录范围之内。
1、kmalloc() 分配连续的物理地址，用于小内存分配。
2、__get_free_page() 分配连续的物理地址，用于整页分配。
至于为什么说以上函数分配的是连续的物理地址和返回的到底是物理地址还是虚拟地址，下面的记录会做出解释。
kmalloc() 函数本身是基于 slab 实现的。slab是为分配小内存提供的一种高效机制。但 slab 这种分配机制又不是独立的，它本身也是在页分配器的基础上来划分更细粒度的内存供调用者使用。也就是说系统先用页分配器分配以页为最小单位的连续物理地址，然后 kmalloc() 再在这上面根据调用者的需要进行切分。关于以上论述，我们可以查看malloc() 的实现，kmalloc()函数的实现是在 __do_kmalloc() 中，可以看到在__do_kmalloc() 代码里最终调用了_cache_alloc() 来分配一个slab，其实kmem_cache_alloc() 等函数的实现也是调用了这个函数来分配新的 slab。我们按_cache_alloc() 函数的调用路径一直跟踪下去会发现在 cache_grow() 函数中使用了kmem_getpages() 函数来分配一个物理，kmem_getpages() 函数中调用的alloc_pages_node() 最终是使用 __alloc_pages() 来返回一个struct page 结构，而这个结构正是系统用来描述物理页面的。这样也就证实了上面所说的，slab 是在物理页面基础上实现的。kmalloc() 分配的是物理地址。
__get_free_page() 是页面分配器提供给调用者的最底层的内存分配函数。它分配连续的物理内。__get_free_page() 函数本身是基于 buddy 实现的。在使用 buddy 实现的物理内存管理中最小分配粒度是以页为单位的。关于以上论述，我们可以查看__get_free_page() 的实现，可以看到 __get_free_page() 函数只是一个非常简单的封状，它的整个函数实现就是无条件的调用 __alloc_pages() 函数来分配物理内存，上面记录 kmalloc()实现时也提到过是在调用_alloc_pages() 函数来分配物理页面的前提下进行的 slab 管理。那么这个函数是如何分配到物理页面又是在什么区域中进行分配的?回答这个问题只能看下相关的实现。可以看到在 __alloc_pages() 函数中，多次尝试调用get_page_from_freelist() 函数从 zonelist 中取得相关 zone，并从其中返回一个可用的 struct page 页面(这里的有些调用分支是因为标志不同)。至此，可以知道一个物理页面的分配是从 zonelist(一个 zone 的结构数组)中的 zone 返回的。那么 zonelist/zone 是如何与物理页面关联，又是如何初始化的呢?继续来看 free_area_init_nodes() 函数，此函数在系统初始化时由 zone_sizes_init() 函数间接调用的，zone_sizes_init()
函数填充了三个区域：ZONE_DMA，ZONE_NORMAL，ZONE_HIGHMEM。并把他们作为参数调用 free_area_init_nodes()，在这个函数中会分配一个 pglist_data 结构，此结构中包含了zonelist/zone结构和一个 struct page 的物理页结构，在函数最后用此结构作为参数调用了 free_area_init_node() 函数，在这个函数中首先使用 calculate_node_totalpages() 函数标记 pglist_data 相关区域，然后调用 alloc_node_mem_map() 函数初始化 pglist_data结构中的 struct page 物理页。最后使用free_area_init_core()函数关联 pglist_data 与 zonelist。可见__get_free_page()是从buddy systems分配的页框。现在通以上分析已经明确了__get_free_page() 函数分配物理内存的流程。但这里又引出了几个新问题，那就是此函数分配的物理页面是如何映射的?映射到了什么位置?到这里不得不去看下与 VMM 相关的引导代码。
在看 VMM 相关的引导代码前，先来看一下virt_to_phys() 与phys_to_virt 这两个函数。顾名思义，即是虚拟地址到物理地址和物理地址到虚拟地址的转换。函数实现十分简单，前者调用了__pa( address ) 转换虚拟地址到物理地址，后者调用 __va( addrress ) 将物理地址转换为虚拟地址。再看下 __pa __va 这两个宏到底做了什么。
#define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)
#define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET))
通过上面可以看到仅仅是把地址加上或减去 PAGE_OFFSET，而PAGE_OFFSET 在 x86 下定义为0xC0000000。这里又引出了疑问，在 linux 下写过 driver 的人都知道，在使用 kmalloc() 与__get_free_page() 分配完物理地址后，如果想得到正确的物理地址需要使用 virt_to_phys() 进行转换。那么为什么要有这一步呢?我们不分配的不就是物理地址么?怎么分配完成还需要转换?如果返回的是虚拟地址，那么根据如上对 virt_to_phys() 的分析，为什么仅仅对 PAGE_OFFSET 操作就能实现地址转换呢?虚拟地址与物理地址之间的转换不需要查页表么?代着以上诸多疑问来看 VMM 相关的引导代码。
直接从 start_kernel() 内核引导部分来查找VMM 相关内容。可以看到第一个应该关注的函数是 setup_arch()，在这个函数当中使用paging_init() 函数来初始化和映射硬件页表(在初始化前已有 8M内存被映射，在这里不做记录)，而 paging_init() 则是调用的pagetable_init() 来完成内核物理地址的映射以及相关内存的初始化。在pagetable_init() 函数中，首先是一些PAE/PSE/PGE 相关判断与设置，然后使用 kernel_physical_mapping_init() 函数来实现内核物理内存的映射。在这个函数中可以很清楚的看到，pgd_idx 是以PAGE_OFFSET 为启始地址进行映射的，也就是说循环初始化所有物理地址是以 PAGE_OFFSET 为起点的。继续观察我们可以看到在 PMD 被初始化后，所有地址计算均是以 PAGE_OFFSET 作为标记来递增的。分析到这里已经很明显的可以看出，物理地址被映射到以 PAGE_OFFSET开始的虚拟地址空间。这样以上所有疑问就都有了答案。kmalloc() 与__get_free_page() 所分配的物理页面被映射到了 PAGE_OFFSET 开始的虚拟地址，也就是说实际物理地址与虚拟地址有一组一一对应的关系，正是因为有了这种映射关系，对内核以 PAGE_OFFSET 启始的虚拟地址的分配也就是对物理地址的分配(当然这有一定的范围，应该在 PAGE_OFFSET
与 VMALLOC_START 之间，后者为vmalloc() 函数分配内存的启始地址)。这也就解释了为什么 virt_to_phys() 与phys_to_virt() 函数的实现仅仅是加/减 PAGE_OFFSET 即可在虚拟地址与物理地址之间转换，正是
因为了有了这种映射，且固定不变，所以才不用去查页表进行转换。这也同样回答了开始的问题，即 kmalloc() / __get_free_page() 分配的是物理地址，而返回的则是虚拟地址(虽然这听上去有些别扭)。正是因为有了这种映射关系，所以需要将它们的返回地址减去 PAGE_OFFSET 才可以得到真正的物理地址。
虚拟地址和物理地址的概念
CPU通过地址来访问内存中的单元，地址有虚拟地址和物理地址之分，如果CPU没有MMU(Memory Management Unit，内存管理单元)，或者有MMU但没有启用，CPU核在取指令或访问内存时发出的地址将直接传到CPU芯片的外部地址引脚上，直接被内存芯片(以下称为物理内存，以便与虚拟内存区分)接收，这称为物理地址(Physical Address，以下简称PA)，如下图所示。
物理地址示意图
如果CPU启用了MMU，CPU核发出的地址将被MMU截获，从CPU到MMU的地址称为虚拟地址(Virtual Address，以下简称VA)，而MMU将这个地址翻译成另一个地址发到CPU芯片的外部地址引脚上，也就是将虚拟地址映射成物理地址，如下图所示[1]。
虚拟地址示意图
MMU将虚拟地址映射到物理地址是以页(Page)为单位的，对于32位CPU通常一页为4K。例如，虚拟地址0xb700 1000~0xb700 1fff是一个页，可能被MMU映射到物理地址0x2000~0x2fff，物理内存中的一个物理页面也称为一个页框(Page Frame)。
内核也不能直接访问物理地址.但因为内核的虚拟地址和物理地址之间只是一个差值0xc0000000的区别,所以从物理地址求虚拟地址或从虚拟地址求物理地址很容易,+-这个差就行了
物理地址(physical address)
用于内存芯片级的单元寻址，与处理器和CPU连接的地址总线相对应。
——这个概念应该是这几个概念中最好理解的一个，但是值得一提的是，虽然可以直接把物理地址理解成插在机器上那根内存本身，把内存看成一个从0字节一直到最大空量逐字节的编号的大数组，然后把这个数组叫做物理地址，但是事实上，这只是一个硬件提供给软件的抽像，内存的寻址方式并不是这样。所以，说它是“与地址总线相对应”，是更贴切一些，不过抛开对物理内存寻址方式的考虑，直接把物理地址与物理的内存一一对应，也是可以接受的。也许错误的理解更利于形而上的抽像。
虚拟内存(virtual memory)
这是对整个内存(不要与机器上插那条对上号)的抽像描述。它是相对于物理内存来讲的，可以直接理解成“不直实的”，“假的”内存，例如，一个0x08000000内存地址，它并不对就物理地址上那个大数组中0x08000000 - 1那个地址元素;
之所以是这样，是因为现代操作系统都提供了一种内存管理的抽像，即虚拟内存(virtual memory)。进程使用虚拟内存中的地址，由操作系统协助相关硬件，把它“转换”成真正的物理地址。这个“转换”，是所有问题讨论的关键。
有了这样的抽像，一个程序，就可以使用比真实物理地址大得多的地址空间。(拆东墙，补西墙，银行也是这样子做的)，甚至多个进程可以使用相同的地址。不奇怪，因为转换后的物理地址并非相同的。
——可以把连接后的程序反编译看一下，发现连接器已经为程序分配了一个地址，例如，要调用某个函数A，代码不是call A，而是call 0x0811111111 ，也就是说，函数A的地址已经被定下来了。没有这样的“转换”，没有虚拟地址的概念，这样做是根本行不通的。
Linux下获取虚拟地址对应的物理地址的方法
* /proc/pid/pagemap. This file lets a userspace process find out which
physical frame each virtual page is mapped to. It contains one 64-bit
value for each virtual page, containing the following data (from
fs/proc/task_mmu.c, above pagemap_read):
* Bits 0-54 page frame number (PFN) if present
* Bits 0-4 swap type if swapped
* Bits 5-54 swap offset if swapped
* Bit 55 pte is soft-dirty (see Documentation/vm/soft-dirty.txt)
* Bits 56-60 zero
* Bit 61 page is file-page or shared-anon
* Bit 62 page swapped
* Bit 63 page present
If the page is not present but in swap, then the PFN contains an
encoding of the swap file number and the page's offset into the
swap. Unmapped pages return a null PFN. This allows determining
precisely which pages are mapped (or in swap) and comparing mapped
pages between processes.
接下来，我们根据上述描述，给出获取虚拟地址对应的物理地址的代码
#include <stdio.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#define page_map_file "/proc/self/pagemap"
#define PFN_MASK ((((uint64_t)1)<<55)-1)
#define PFN_PRESENT_FLAG (((uint64_t)1)<<63)
int mem_addr_vir2phy(unsigned long vir, unsigned long *phy)
{
int fd;
int page_size=getpagesize();
unsigned long vir_page_idx = vir/page_size;
unsigned long pfn_item_offset = vir_page_idx*sizeof(uint64_t);
uint64_t pfn_item;
fd = open(page_map_file, O_RDONLY);
if (fd<0)
{
printf("open %s failed", page_map_file);
return -1;
}
if ((off_t)-1 == lseek(fd, pfn_item_offset, SEEK_SET))
{
printf("lseek %s failed", page_map_file);
return -1;
}
if (sizeof(uint64_t) != read(fd, &pfn_item, sizeof(uint64_t)))
{
printf("read %s failed", page_map_file);
return -1;
}
if (0==(pfn_item & PFN_PRESENT_FLAG))
{
printf("page is not present");
return -1;
}
*phy = (pfn_item & PFN_MASK)*page_size + vir % page_size;
return 0;
}
如果担心vir地址对应的页面不在内存中，可以在调用mem_addr_vir2phy之前，先访问一下此地址。
例如， int a=*(int *)(void *)vir;
如果担心Linux的swap功能将进程的页面交换到硬盘上从而导致页面的物理地址变化，可以关闭swap功能。
下面两个C库函数可以阻止Linux将当前进程的部分或全部页面交换到硬盘上。
int mlock(const void *addr, size_t len);
int mlockall(int flags);
看过“虚拟地址物理地址linux ”的人还看了：