linux 用户态和内核态以及进程上下文、中断上下文 内核空间用户空间理解
免费下载资源
处理器总处于以下状态中的一种：
1、内核态，运行于进程上下文，内核代表进程运行于内核空间；
2、内核态，运行于中断上下文，内核代表硬件运行于内核空间；
3、用户态，运行于用户空间。
内核空间和用户空间是操作系统重要的理论知识，用户程序运行在用户空间，内核功能模块运行在内核空间，二者是空间是不能互相访问的，内核空间和用户空间指其代码和数据存放内存空间。用户态的程序要想访问内核空间，须使用系统调用。当用户空间的应用程序通过系统调用进入内核空间时，就会涉及到上下文的切换。用户空间和内核空间具有不同的地址映射、通用寄存器和专用寄存器组以及堆栈区，而且用户空间的进程要传递很多变量、参数给内核，内核也要保存用户进程的一些寄存器、变量等，以便系统调用结束后回到用户空间继续执行。
所谓的进程上下文，就是一个进程传递给内核的那些参数和CPU的所有寄存器的值、进程的状态以及堆栈中的内容，也就进程在进入内核态之前的运行环境。所以在切换到内核态时需要保存当前进程的所有状态，即保存当前进程的上下文，以便再次执行该进程时，能够恢复切换时的状态，继续执行。同理，硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理，中断上下文就可以理解为硬件传递过来的这些参数和内核需要保存的一些环境（主要是被中断的进程的环境）。
当一个进程在执行时,CPU的所有寄存器中的值、进程的状态以及堆栈中的内容被称为该进程的上下文。当内核需要切换到另一个进程时，它需要保存当前进程的所有状态，即保存当前进程的上下文，以便在再次执行该进程时，能够必得到切换时的状态执行下去。在LINUX中，当前进程上下文均保存在进程的任务数据结构中。在发生中断时,内核就在被中断进程的上下文中，在内核态下执行中断服务例程。但同时会保留所有需要用到的资源，以便中继服务结束时能恢复被中断进程的执行。
上下文简单说来就是一个环境，相对于进程而言，就是进程执行时的环境。相对于中断而言就是中断执行时的环境。
一个进程的上下文可以分为三个部分:用户级上下文、寄存器上下文以及系统级上下文。
（1）用户级上下文: 正文、数据、用户堆栈以及共享存储区；
（2）寄存器上下文: 通用寄存器、程序寄存器(IP)、处理器状态寄存器(EFLAGS)、栈指针(ESP)；
（3）系统级上下文: 进程控制块task_struct、内存管理信息(mm_struct、vm_area_struct、pgd、pte)、内核栈。
进程上下文切换分为进程调度时和系统调用时两种切换，消耗资源不同，当发生进程调度时，进行进程切换就是上下文切换(context switch).操作系统必须对上面提到的全部信息进行切换，新调度的进程才能运行。而系统调用进行的模式切换(mode switch)与进程切换比较起来，容易很多，而且节省时间，因为模式切换最主要的任务只是切换进程寄存器上下文的切换。在进程上下文中，可以用current宏关联当前进程，也可以睡眠，也可以调用调度程序。
中断上下文不支持抢占，运行在进程上下文的内核代码是可以被抢占的（Linux2.6支持抢占），就是支持进程调度。但是一个中断上下文，通常都会始终占有CPU（当然中断可以嵌套，但我们一般不这样做），不可以被打断。正因为如此，运行在中断上下文的代码就要受一些限制，不能做下面的事情：
（1）睡眠或者放弃CPU。
这样做的后果是灾难性的，因为内核在进入中断之前会关闭进程调度，一旦睡眠或者放弃CPU，这时内核无法调度别的进程来执行，系统就会死掉
（2）尝试获得信号量、执行自旋锁
如果获得不到信号量，代码就会睡眠，会产生和上面相同的情况
（3）执行耗时的任务
中断处理应该尽可能快，因为内核要响应大量服务和请求，中断上下文占用CPU时间太长会严重影响系统功能。
（4）访问用户空间的虚拟地址
因为中断上下文是和特定进程无关的，它是内核代表硬件运行在内核空间，所以在中断上下文无法访问用户空间的虚拟地址
用户空间与内核空间
我们知道现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操心系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核，保证内核的安全，操心系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间，而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。每个进程可以通过系统调用进入内核，因此，Linux内核由系统内的所有进程共享。于是，从具体进程的角度来看，每个进程可以拥有4G字节的虚拟空间。空间分配如下图所示：
有了用户空间和内核空间，整个linux内部结构可以分为三部分，从最底层到最上层依次是：硬件-->内核空间-->用户空间。如下图所示：
需要注意的细节问题：
从上图可以看出内核的组成
（1） 内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据。不管是内核空间还是用户空间，它们都处于虚拟空间中。
（2） Linux使用两级保护机制：0级供内核使用，3级供用户程序使用。
为什么不把所有的地址空间都分配给内核？
若把所有地址空间都给内存，那么用户进程怎么使用内存？怎么保证内核使用内存和用户进程不起冲突？
（1）让我们忽略Linux对段式内存映射的支持。 在保护模式下，我们知道无论CPU运行于用户态还是核心态，CPU执行程序所访问的地址都是虚拟地址，MMU 必须通过读取控制寄存器CR3中的值作为当前页面目录的指针，进而根据分页内存映射机制（参看相关文档）将该虚拟地址转换为真正的物理地址才能让CPU真 正的访问到物理地址。
（2）对于32位的Linux，其每一个进程都有4G的寻址空间，但当一个进程访问其虚拟内存空间中的某个地址时又是怎样实现不与其它进程的虚拟空间混淆 的呢？每个进程都有其自身的页面目录PGD，Linux将该目录的指针存放在与进程对应的内存结构task_struct.(struct mm_struct)mm->pgd中。每当一个进程被调度（schedule()）即将进入运行态时，Linux内核都要用该进程的PGD指针设 置CR3（switch_mm()）。
（3）当创建一个新的进程时，都要为新进程创建一个新的页面目录PGD，并从内核的页面目录swapper_pg_dir中复制内核区间页面目录项至新建进程页面目录PGD的相应位置，具体过程如下：
do_fork() --> copy_mm() --> mm_init() --> pgd_alloc() --> set_pgd_fast() --> get_pgd_slow() --> memcpy(&PGD + USER_PTRS_PER_PGD, swapper_pg_dir + USER_PTRS_PER_PGD, (PTRS_PER_PGD - USER_PTRS_PER_PGD) * sizeof(pgd_t))
这样一来，每个进程的页面目录就分成了两部分，第一部分为“用户空间”，用来映射其整个进程空间（0x0000 0000－0xBFFF FFFF）即3G字节的虚拟地址；第二部分为“系统空间”，用来映射（0xC000 0000－0xFFFF FFFF）1G字节的虚拟地址。可以看出Linux系统中每个进程的页面目录的第二部分是相同的，所以从进程的角度来看，每个进程有4G字节的虚拟空间， 较低的3G字节是自己的用户空间，最高的1G字节则为与所有进程以及内核共享的系统空间。
（4）现在假设我们有如下一个情景：
在进程A中通过系统调用sethostname(const char *name,seze_t len)设置计算机在网络中的“主机名”.
在该情景中我们势必涉及到从用户空间向内核空间传递数据的问题，name是用户空间中的地址，它要通过系统调用设置到内核中的某个地址中。让我们看看这个 过程中的一些细节问题：系统调用的具体实现是将系统调用的参数依次存入寄存器ebx,ecx,edx,esi,edi（最多5个参数，该情景有两个 name和len），接着将系统调用号存入寄存器eax，然后通过中断指令“int 80”使进程A进入系统空间。由于进程的CPU运行级别小于等于为系统调用设置的陷阱门的准入级别3，所以可以畅通无阻的进入系统空间去执行为int 80设置的函数指针system_call()。由于system_call()属于内核空间，其运行级别DPL为0，CPU要将堆栈切换到内核堆栈，即 进程A的系统空间堆栈。我们知道内核为新建进程创建task_struct结构时，共分配了两个连续的页面，即8K的大小，并将底部约1k的大小用于 task_struct（如#define alloc_task_struct() ((struct task_struct *) __get_free_pages(GFP_KERNEL,1))）,而其余部分内存用于系统空间的堆栈空间，即当从用户空间转入系统空间时，堆栈指针 esp变成了（alloc_task_struct()+8192），这也是为什么系统空间通常用宏定义current（参看其实现）获取当前进程的 task_struct地址的原因。每次在进程从用户空间进入系统空间之初，系统堆栈就已经被依次压入用户堆栈SS、用户堆栈指针ESP、EFLAGS、 用户空间CS、EIP，接着system_call()将eax压入，再接着调用SAVE_ALL依次压入ES、DS、EAX、EBP、EDI、ESI、 EDX、ECX、EBX，然后调用sys_call_table+4*%EAX，本情景为sys_sethostname()。
（5）在sys_sethostname()中，经过一些保护考虑后，调用copy_from_user(to,from,n），其中to指向内核空间 system_utsname.nodename，譬如0xE625A000，from指向用户空间譬如0x8010FE00。现在进程A进入了内核，在 系统空间中运行，MMU根据其PGD将虚拟地址完成到物理地址的映射，最终完成从用户空间到系统空间数据的复制。准备复制之前内核先要确定用户空间地址和 长度的合法性，至于从该用户空间地址开始的某个长度的整个区间是否已经映射并不去检查，如果区间内某个地址未映射或读写权限等问题出现时，则视为坏地址， 就产生一个页面异常，让页面异常服务程序处理。过程如 下：copy_from_user()->generic_copy_from_user()->access_ok()+__copy_user_zeroing().
（6）小结：
*进程寻址空间0~4G
*进程在用户态只能访问0~3G，只有进入内核态才能访问3G~4G
*进程通过系统调用进入内核态
*每个进程虚拟空间的3G~4G部分是相同的
*进程从用户态进入内核态不会引起CR3的改变但会引起堆栈的改变
MMU是存储器管理单元的缩写，是用来管理虚拟内存系统的器件。MMU通常是CPU的一部分，本身有少量存储空间存放从虚拟地址到物理地址的匹配表，一种转换方法（算法）。此表称作TLB(转换旁置缓冲区)。所有数据请求都送往MMU，由MMU决定数据是在RAM内还是在大容量存储器设备内。如果数据不在存储空间内，MMU将产生页面错误中断，外部存储器地址空间由页、行、列组成。
MMU的两个主要功能是:
1. 将虚地址转换成物理地址。
2. 控制存储器存取允许。MMU关掉时，虚地址直接输出到物理地址总线：比如uboot前部分。
在实践中，使用MMU解决了如下几个问题：
①使用DRAM作为大容量存储器时，如果DRAM的物理地址不连续，这将给程序的编写调试造成极大不便，而适当配置MMU可将其转换成虚拟地址连续的空间，将不连续的物理空间变为连续的虚拟地址空间。
②ARM内核的中断向量表要求放在0地址，对于ROM在0地址的情况，无法调试中断服务程序，所以在调试阶段有必要将可读写的存储器空间映射到0地址。
③系统的某些地址段是不允许被访问的，否则会产生不可预料的后果,为了避免这类错误,可以通过MMU匹配表的设置将这些地址段设为用户不可存取类型，即内核空间和用户空间区别。
启动程序中生成的匹配表中包含地址映射，存储页大小(1M,64K,或4K)以及是否允许存取等信息，这是实现上述功能基础。
例如:目标板上的16兆DRAM的物理地址区间为0xc000,0000～0xc07f,ffff，;0xc100,0000～0xc17f,ffff;这些地址都是逻辑地址即一个地址一个8位数据，16兆ROM的虚拟地址区间为:0x0000,0000～0x00ff,ffff。匹配表配置（匹配表输入有虚拟地址 页大小 是否允许存取 页表）如下:
可以看到左边是连续的虚拟地址空间，右边是不连续的物理地址空间，而且将DRAM映射到了0地址区间。 MMU通过虚拟地址和页面表位置信息，按照转换逻辑获得对应物理地址，输出到地址总线上。
应注意到的是使能MMU后，程序继续运行，但是对于程序员来说程序计数器的指针已经改变，指向了ROM所对应的虚拟地址。
MMU的作用有两个
MMU的作用有两个：地址翻译和地址保护 软件的职责是配置页表，硬件的职责是根据页表完成地址翻译和保护工作。 那三个函数是用来访问页表的。如果cpu没有硬件MMU那么这张表将毫无意义。 你必须从cpu的角度去理解内存映射这个概念。内存映射不是调用一个函数，然后读取返回值。而是cpu通过MMU把一条指令中要访问的地址转换为物理地址，然后发送到总线上的过程。 有本书叫做understand linux kernel，耐心看，那本书写的非常好。
MMU是处理器复杂到一定程度出现的产物。这个东西和操作系统的内存管理如果结合起来学习和理解，效果最好。
嵌入式系统中，存储系统差别很大，可包含多种类型的存储器件，如FLASH，SRAM，SDRAM，ROM等，这些不同类型的存储器件速度和宽度等各不相同；在访问存储单元时，可能采取平板式的地址映射机制对其操作，或需要使用虚拟地址对其进行读写；系统中，需引入存储保护机制，增强系统的安全性。为适应如此复杂的存储体系要求，ARM处理器中引入了存储管理单元来管理存储系统，这是mmu意义。
一 内存管理单元（MMU）概述
在ARM存储系统中，使用MMU实现虚拟地址到实际物理地址的映射。为何要实现这种映射？首先就要从一个嵌入式系统的基本构成和运行方式着手。系统上电时，处理器的程序指针从0x0（或者是由0Xffff_0000处高端启动）处启动，顺序执行程序，在程序指针（PC）启动地址，属于非易失性存储器空间范围，如ROM、FLASH等。然而与上百兆的嵌入式处理器相比，FLASH、ROM等存储器响应速度慢，已成为提高系统性能的一个瓶颈。而SDRAM具有很高的响应速度，为何不使用SDRAM来执行程序呢？为了提高系统整体速度，可以这样设想，利用FLASH、ROM对系统进行配置，把真正的应用程序下载到SDRAM中运行，这样就可以提高系统的性能。然而这种想法又遇到了另外一个问题，当ARM处理器响应异常事件时，程序指针将要跳转到一个确定的位置，假设发生了IRQ中断，PC将指向0x18(如果为高端启动，则相应指向0vxffff_0018处)，而此时0x18处仍为非易失性存储器所占据的位置，则程序的执行还是有一部分要在FLASH或者ROM中来执行的。那么我们可不可以使程序完全都SDRAM中运行那？答案是肯定的，这就引入了MMU，利用MMU，可把SDRAM的地址完全映射到0x0起始的一片连续地址空间，而把原来占据这片空间的FLASH或者ROM映射到其它不相冲突的存储空间位置。例如，FLASH的地址从0x0000_0000－0x00ff_ffff,而SDRAM的地址范围是0x3000_0000－0x31ff_ffff，则可把SDRAM地址映射为0x0000_0000－0x1fff_ffff而FLASH的地址可以映射到0x9000_0000－0x90ff_ffff（此处地址空间为空闲，未被占用）。映射完成后，如果处理器发生异常，假设依然为IRQ中断，PC指针指向0x18处的地址，而这个时候PC实际上是从位于物理地址的0x3000_0018处读取指令。通过MMU的映射，则可实现程序完全运行在SDRAM之中，这些物理器件的地址是实际的挂载到总线上的地址。
在实际的应用中，可能会把两片不连续的物理地址空间分配给SDRAM。而在操作系统中，习惯于把SDRAM的空间连续起来，方便内存管理，且应用程序申请大块的内存时，操作系统内核也可方便地分配。通过MMU可实现不连续的物理地址空间映射为连续的虚拟地址空间。
操作系统内核或者一些比较关键的代码，一般是不希望被用户应用程序所访问的。通过MMU可以控制地址空间的访问权限，从而保护这些代码不被破坏，内核空间与用户空间区别。
GitHub 加速计划 / li / linux-dash
10.39 K
1.2 K
下载
旨在为数千万中国开发者提供一个无缝且高效的云端环境，以支持学习、使用和贡献开源项目。
更多推荐
16
0- 0
已为社区贡献5条内容
所有评论(0)