ioremap 与 mmap【转】

简介:

转自:http://blog.csdn.net/junllee/article/details/7415732

内存映射

    对于提供了MMU(存储管理器,辅助操作系统进行内存管理,提供虚实地址转换等硬件支持)的处理器而言,Linux提供了复杂的存储管理系统,使得进程所能访问的内存达到4GB。

进程的4GB内存空间被人为的分为两个部分--用户空间与内核空间。用户空间地址分布从0到3GB(PAGE_OFFSET,在0x86中它等于0xC0000000),3GB到4GB为内核空间,如下图:

内核空间中,从3G到vmalloc_start这段地址是物理内存映射区域(该区域中包含了内核镜像、物理页框表mem_map等等),比如我们使用的VMware虚拟系统内存是160M,那么3G~3G+160M这片内存就应该映射物理内存。在物理内存映射区之后,就是vmalloc区域。对于 160M的系统而言,vmalloc_start位置应在3G+160M附近(在物理内存映射区与vmalloc_start期间还存在一个8M的gap 来防止跃界),vmalloc_end的位置接近4G(最后位置系统会保留一片128k大小的区域用于专用页面映射),如下图:

kmalloc和get_free_page申请的内存位于物理内存映射区域,而且在物理上也是连续的,它们与真实的物理地址只有一个固定的偏移,因此存在较简单的转换关系,virt_to_phys()可以实现内核虚拟地址转化为物理地址:

#define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)

extern inline unsigned long virt_to_phys(volatile void * address)

{

return __pa(address);

}

上面转换过程是将虚拟地址减去3G(PAGE_OFFSET=0XC000000)。

与之对应的函数为phys_to_virt(),将内核物理地址转化为虚拟地址:

#define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET))

extern inline void * phys_to_virt(unsigned long address)

{

return __va(address);

}

virt_to_phys()和phys_to_virt()都定义在include\asm-i386\io.h中。

而vmalloc申请的内存则位于vmalloc_start~vmalloc_end之间,与物理地址没有简单的转换关系,虽然在逻辑上它们也是连续的,但是在物理上它们不要求连续。

我们用下面的程序来演示kmalloc、get_free_page和vmalloc的区别:

#include 

#include 

#include 

MODULE_LICENSE("GPL"); 

unsigned char *pagemem;

unsigned char *kmallocmem;

unsigned char *vmallocmem;

int __init mem_module_init(void)

{

//最好每次内存申请都检查申请是否成功

//下面这段仅仅作为演示的代码没有检查

pagemem = (unsigned char*)get_free_page(0);

printk("pagemem addr=%x", pagemem);

kmallocmem = (unsigned char*)kmalloc(100, 0);

printk("kmallocmem addr=%x", kmallocmem);

vmallocmem = (unsigned char*)vmalloc(1000000);

printk("vmallocmem addr=%x", vmallocmem);

return 0;

}

void __exit mem_module_exit(void)

{

free_page(pagemem);

kfree(kmallocmem);

vfree(vmallocmem);

}

module_init(mem_module_init);

module_exit(mem_module_exit);

我们的系统上有160MB的内存空间,运行一次上述程序,发现pagemem的地址在0xc7ArrayArray7000(约3G+121M)、kmallocmem 地址在0xcArraybc1380(约3G+155M)、vmallocmem的地址在0xcabeb000(约3G+171M)处,符合前文所述的内存布局。

接下来,我们讨论Linux设备驱动究竟怎样访问外设的I/O端口(寄存器)。

几乎每一种外设都是通过读写设备上的寄存器来进行的,通常包括控制寄存器、状态寄存器和数据寄存器三大类,外设的寄存器通常被连续地编址。根据CPU体系结构的不同,CPU对IO端口的编址方式有两种:

(1)I/O映射方式(I/O-mapped)

典型地,如X86处理器为外设专门实现了一个单独的地址空间,称为"I/O地址空间"或者"I/O端口空间",CPU通过专门的I/O指令(如X86的IN和OUT指令)来访问这一空间中的地址单元。

(2)内存映射方式(Memory-mapped)

RISC指令系统的CPU(如ARM、PowerPC等)通常只实现一个物理地址空间,外设I/O端口成为内存的一部分。此时,CPU可以象访问一个内存单元那样访问外设I/O端口,而不需要设立专门的外设I/O指令。

但是,这两者在硬件实现上的差异对于软件来说是完全透明的,驱动程序开发人员可以将内存映射方式的I/O端口和外设内存统一看作是"I/O内存"资源。

一般来说,在系统运行时,外设的I/O内存资源的物理地址是已知的,由硬件的设计决定。但是CPU通常并没有为这些已知的外设I/O内存资源的物理地址预定义虚拟地址范围,驱动程序并不能直接通过物理地址访问I/O内存资源,而必须将它们映射到核心虚地址空间内(通过页表),然后才能根据映射所得到的核心虚地址范围,通过访内指令访问这些I/O内存资源。Linux在io.h头文件中声明了函数ioremap(),用来将I/O内存资源的物理地址映射到核心虚地址空间(3GB-4GB)中,原型如下:

void * ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags);

iounmap函数用于取消ioremap()所做的映射,原型如下:

void iounmap(void * addr);

这两个函数都是实现在mm/ioremap.c文件中。

在将I/O内存资源的物理地址映射成核心虚地址后,理论上讲我们就可以象读写RAM那样直接读写I/O内存资源了。为了保证驱动程序的跨平台的可移植性,我们应该使用Linux中特定的函数来访问I/O内存资源,而不应该通过指向核心虚地址的指针来访问。如在x86平台上,读写I/O的函数如下所示:

#define readb(addr) (*(volatile unsigned char *) __io_virt(addr))

#define readw(addr) (*(volatile unsigned short *) __io_virt(addr))

#define readl(addr) (*(volatile unsigned int *) __io_virt(addr))

#define writeb(b,addr) (*(volatile unsigned char *) __io_virt(addr) = (b))

#define writew(b,addr) (*(volatile unsigned short *) __io_virt(addr) = (b))

#define writel(b,addr) (*(volatile unsigned int *) __io_virt(addr) = (b))

#define memset_io(a,b,c) memset(__io_virt(a),(b),(c))

#define memcpy_fromio(a,b,c) memcpy((a),__io_virt(b),(c))

#define memcpy_toio(a,b,c) memcpy(__io_virt(a),(b),(c))

最后,我们要特别强调驱动程序中mmap函数的实现方法。用mmap映射一个设备,意味着使用户空间的一段地址关联到设备内存上,这使得只要程序在分配的地址范围内进行读取或者写入,实际上就是对设备的访问。

笔者在Linux源代码中进行包含"ioremap"文本的搜索,发现真正出现的ioremap的地方相当少。所以笔者追根索源地寻找I/O操作的物理地址转换到虚拟地址的真实所在,发现Linux有替代ioremap的语句,但是这个转换过程却是不可或缺的。

譬如我们再次摘取S3C2410这个ARM芯片RTC(实时钟)驱动中的一小段:

static void get_rtc_time(int alm, struct rtc_time *rtc_tm)

{

spin_lock_irq(&rtc_lock);

if (alm == 1) {

rtc_tm->tm_year = (unsigned char)ALMYEAR & Msk_RTCYEAR;

rtc_tm->tm_mon = (unsigned char)ALMMON & Msk_RTCMON;

rtc_tm->tm_mday = (unsigned char)ALMDAY & Msk_RTCDAY;

rtc_tm->tm_hour = (unsigned char)ALMHOUR & Msk_RTCHOUR;

rtc_tm->tm_min = (unsigned char)ALMMIN & Msk_RTCMIN;

rtc_tm->tm_sec = (unsigned char)ALMSEC & Msk_RTCSEC;

}

else {

read_rtc_bcd_time:

rtc_tm->tm_year = (unsigned char)BCDYEAR & Msk_RTCYEAR;

rtc_tm->tm_mon = (unsigned char)BCDMON & Msk_RTCMON;

rtc_tm->tm_mday = (unsigned char)BCDDAY & Msk_RTCDAY;

rtc_tm->tm_hour = (unsigned char)BCDHOUR & Msk_RTCHOUR;

rtc_tm->tm_min = (unsigned char)BCDMIN & Msk_RTCMIN;

rtc_tm->tm_sec = (unsigned char)BCDSEC & Msk_RTCSEC;

if (rtc_tm->tm_sec == 0) {

/* Re-read all BCD registers in case of BCDSEC is 0.

See RTC section at the manual for more info. */

goto read_rtc_bcd_time;

}

}

spin_unlock_irq(&rtc_lock);

BCD_TO_BIN(rtc_tm->tm_year);

BCD_TO_BIN(rtc_tm->tm_mon);

BCD_TO_BIN(rtc_tm->tm_mday);

BCD_TO_BIN(rtc_tm->tm_hour);

BCD_TO_BIN(rtc_tm->tm_min);

BCD_TO_BIN(rtc_tm->tm_sec);

/* The epoch of tm_year is 1Array00 */

rtc_tm->tm_year += RTC_LEAP_YEAR - 1Array00;

/* tm_mon starts at 0, but rtc month starts at 1 */

rtc_tm->tm_mon--;

}

I/O操作似乎就是对ALMYEAR、ALMMON、ALMDAY定义的寄存器进行操作,那这些宏究竟定义为什么呢?

#define ALMDAY bRTC(0x60)

#define ALMMON bRTC(0x64)

#define ALMYEAR bRTC(0x68)

其中借助了宏bRTC,这个宏定义为:

#define bRTC(Nb) __REG(0x57000000 + (Nb))

其中又借助了宏__REG,而__REG又定义为:

# define __REG(x) io_p2v(x)

最后的io_p2v才是真正"玩"虚拟地址和物理地址转换的地方: 

#define io_p2v(x) ((x) | 0xa0000000)

与__REG对应的有个__PREG:

# define __PREG(x) io_v2p(x)

与io_p2v对应的有个io_v2p:

#define io_v2p(x) ((x) & ~0xa0000000)

可见有没有出现ioremap是次要的,关键问题是有无虚拟地址和物理地址的转换!

下面的程序在启动的时候保留一段内存,然后使用ioremap将它映射到内核虚拟空间,同时又用remap_page_range映射到用户虚拟空间,这样一来,内核和用户都能访问。如果在内核虚拟地址将这段内存初始化串"abcd",那么在用户虚拟地址能够读出来:

/************mmap_ioremap.c**************/

#include 

#include 

#include 

#include 

#include  /* for mem_map_(un)reserve */

#include  /* for virt_to_phys */

#include  /* for kmalloc and kfree */

MODULE_PARM(mem_start, "i");

MODULE_PARM(mem_size, "i");

static int mem_start = 101, mem_size = 10;

static char *reserve_virt_addr;

static int major;

int mmapdrv_open(struct inode *inode, struct file *file);

int mmapdrv_release(struct inode *inode, struct file *file);

int mmapdrv_mmap(struct file *file, struct vm_area_struct *vma);

static struct file_operations mmapdrv_fops =

{

owner: THIS_MODULE, mmap: mmapdrv_mmap, open: mmapdrv_open, release:

mmapdrv_release,

};

int init_module(void)

{

if ((major = register_chrdev(0, "mmapdrv", &mmapdrv_fops)) vm_pgoff vm_end - vma->vm_start;

if (size > mem_size *1024 * 1024)

{

printk("size too big\n");

return ( - ENXIO);

}

offset = offset + mem_start * 1024 * 1024;

/* we do not want to have this area swapped out, lock it */

vma->vm_flags |= VM_LOCKED;

if (remap_page_range(vma, vma->vm_start, offset, size, PAGE_SHARED))

{

printk("remap page range failed\n");

return - ENXIO;

}

return (0);

}

remap_page_range函数的功能是构造用于映射一段物理地址的新页表,实现了内核空间与用户空间的映射,其原型如下: 

int remap_page_range(vma_area_struct *vma, unsigned long from, unsigned long to, unsigned long size, pgprot_tprot); 

使用mmap最典型的例子是显示卡的驱动,将显存空间直接从内核映射到用户空间将可提供显存的读写效率。










本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/sky-heaven/p/4757207.html,如需转载请自行联系原作者

相关文章
mmap实现共享内存
mmap实现共享内存
181 0
|
NoSQL MongoDB Python
python mongodb pymongo 连接 身份认证
python mongodb pymongo 连接 身份认证
204 0
|
存储 JSON NoSQL
Python连接MongoDB操作
Python连接MongoDB操作
581 1
|
IDE Java Maven
idea2020版Maven依赖成功导入但仍然报错找不到包解决
idea2020版Maven依赖成功导入但仍然报错找不到包解决
1830 0
idea2020版Maven依赖成功导入但仍然报错找不到包解决
|
2月前
|
机器学习/深度学习 资源调度 搜索推荐
淘宝API用户画像生成,个性化推荐下单率提升!
在电商竞争激烈的环境下,淘宝通过API驱动的用户画像与个性化推荐系统,有效提升用户下单率。本文解析其技术原理,涵盖数据处理、推荐算法及效果量化,展现如何实现15%以上的下单率增长,助力开发者与商家优化业务策略。
121 0
|
8月前
|
机器学习/深度学习 人工智能 自然语言处理
《解锁元宇宙虚拟角色自主行为:AI与深度强化学习的融合变革》
元宇宙作为新兴领域,融合了VR、AR等技术,其虚拟角色的智能行为至关重要。目前,虚拟角色行为较为简单,缺乏自主性。AI与深度强化学习的结合为虚拟角色带来了“智慧大脑”,通过自然语言处理和计算机视觉技术,使虚拟角色能理解用户意图并作出合理反应。深度强化学习则让虚拟角色在互动中不断优化决策策略,提升社交、游戏和工作场景中的用户体验。尽管面临样本效率低、可解释性差等挑战,AI与DRL的融合将推动虚拟角色更加智能和个性化,开启人类与虚拟世界交互的新篇章。
176 4
|
6月前
|
JavaScript 前端开发 Java
Spring Boot 与 Vue.js 前后端分离中的数据交互机制
本文深入探讨了Spring Boot与Vue.js在前后端分离架构下的数据交互机制。通过对比传统`model.addAttribute()`方法与RESTful API的设计,分析了两者在耦合性、灵活性及可扩展性方面的差异。Spring Boot以RESTful API提供数据服务,Vue.js借助Axios消费API并动态渲染页面,实现了职责分明的解耦架构。该模式显著提升了系统的灵活性和维护性,适用于复杂应用场景如论坛、商城系统等,为现代Web开发提供了重要参考。
493 0
|
资源调度 JavaScript API
解锁一个尚未被 Vue 正式实现的提案或想法集合的库,真的很有趣!
解锁一个尚未被 Vue 正式实现的提案或想法集合的库,真的很有趣!
|
安全 Java 数据安全/隐私保护
Spring Boot 3 集成 Jasypt详解
随着信息安全的日益受到重视,加密敏感数据在应用程序中变得越来越重要。Jasypt(Java Simplified Encryption)作为一个简化Java应用程序中数据加密的工具,为开发者提供了一种便捷而灵活的加密解决方案。
1171 3
Spring Boot 3 集成 Jasypt详解
|
API Android开发 开发者
Android Studio Electric Eel | 2022.1.1 版本
Android Studio Electric Eel | 2022.1.1 版本
459 0