mirror of
https://github.com/superconvert/smart-os.git
synced 2024-11-22 02:04:23 +08:00
Add files via upload
This commit is contained in:
superconvert
GitHub
parent
e52c566997
commit
f489a35d32
55
初识 initramfs .md
Normal file
55
初识 initramfs .md
Normal file
@ -0,0 +1,55 @@
|
|||||||
|
# 简述
|
||||||
|
内核启动时，并没加载根文件系统，有些是内核启动阶段不易完成的工作（驱动现在和内核很多都是分开的，位于外存储系统上，所以内核启动后很多事情都做不了），还有些根文件系统是加密的，反正有多种限制和需求。
|
||||||
|
所以内核启动后会先启动一个内存模式的根文件系统，通常就是 initramfs ，早期一般都是采用 initrd， initrd 是一个位于内存中的完整模拟的块设备，需要整个文件系统的开销，有固定的大小，不灵活，它是一个真
|
||||||
|
实的，静态的设备，消耗 Linux 内核中的缓存和文件分页，带来更多的内存开销. 鉴于 initrd 存在很多弊端，后续逐步被 initramfs 所代替. initramfs 不是设备，而是能直接运行在内存中的根文件系统，规避了 initrd
|
||||||
|
的弊端，好处大大的。
|
||||||
|
|
||||||
|
### 为什么驱动不集成到内核？
|
||||||
|
1. Linux 是一个通用的系统，目标是针对各种不同的硬件平台，况且还有很多新的设备源源不断的出来并集成到内核，将所有的驱动全部集成到内核非常不合理，因此需要把驱动和内核解耦分开，通常这些驱动模块编译成模块，存在外部的根文件系统中
|
||||||
|
2. 根文件系统不可能在一个简单的硬盘上，当使用磁盘阵列 RAID 时，根文件系统可能跨几个存储设备，根文件系统也可能在某个网络设备上，比如：NFS ，还需要网络配置，网络认证，还有加解密的需要，等各种需求场景
|
||||||
|
为了解决这些问题，initramfs 横空出世，initramfs 是一个临时的文件系统，其中包含了必要的设备如硬盘、网卡、文件系统等的驱动以及加载驱动的工具及其运行环境，比如基本的 C 库，动态库的链接加载器等等
|
||||||
|
|
||||||
|
早期的处理时基于 initrd ， initrd 是基于 ramdisk 技术的，而 ramdisk 就是一个基于内存的块设备，因此 initrd 也具有块设备的一切属性。比如 initrd 容量是固定的，一旦创建 initrd 时设定了一个大小，就不能再进行动态调整，所以后续被 initramfs 逐步代替
|
||||||
|
|
||||||
|
# initramfs 的好处
|
||||||
|
我们知道 Linux 存在着 live 版本，live 启动后会卸载光盘，把系统加载到内存中，这样尝试一个新系统或对另一个系统进行修复时不会伤害到已安装的系统，非常方便。
|
||||||
|
此外还可以
|
||||||
|
1. 加载模块，如第三方驱动
|
||||||
|
2. 定制化启动系统
|
||||||
|
3. 制作一个很小的 rescue shell
|
||||||
|
4. 内核不能，但是用户态可以完成的命令
|
||||||
|
5. 逻辑卷管理器
|
||||||
|
6. 软件 RAID
|
||||||
|
7. 蓝牙驱动
|
||||||
|
|
||||||
|
# initramfs 的组成
|
||||||
|
内核挂载 initramfs 时，文件系统的根分区并没挂载，所以无法访问文件系统中的文件。所以 initramfs 至少包含一个文件 /init ，内核的第一个进程，就是咱们常常听说的大名鼎鼎的 init 进程。
|
||||||
|
别的根据需要定制，当然 /usr, /bin 等目录也是必要的。initramfs 是通过 cpio 进行归档的，能够兼容大部分设备。
|
||||||
|
|
||||||
|
# initramfs 的运行
|
||||||
|
initramfs 通常和内核一起存储，bootloader 引导内核时，通常会把 initramfs 以参数的形式传递给内核，内核检测到 initramfs ，会创建一个 tmpfs 文件系统，并把 initramfs 解压到 tmpfs 中，内核启动 tmpfs 文件系统中的 init 脚本，该程序将探测硬件设备、加载驱动，挂载真正的文件系统，执行文件系统上的 /sbin/init，进而切换到真正的用户空间。真正的文件系统挂载后，initramfs 即完成了使命，其占用的内存也会被释放，继而进行后续的启动过程
|
||||||
|
|
||||||
|
当2.6版本的内核引导时，在挂载真正的根文件系统之前，首先将挂载一个名为 rootfs 的文件系统，并将 rootfs 的根作为虚拟文件系统目录树的总根。那么为什么要使用 rootfs 这么一个中间过程呢？原因之一还是为了解决鸡和蛋的问题。内核需要根文件系统上的驱动以及程序来驱动和挂载根文件系统，但是这些驱动和程序有可能没有编译进内核，而在根文件系统上。如果不借助第三方，内核是没有办法挂载真正的根文件系统的。而 rootfs 虽然名称为 rootfs，但是并不是什么新的文件系统，事实上，rootfs 就是一个 ramfs，只不过换了一个名称。换句话说，rootfs 是在内存中的，内核不需要特殊的驱动就可以挂载 rootfs，所以内核使用 rootfs 作为一个过渡的桥梁。
|
||||||
|
|
||||||
|
在挂载了 rootfs 后，内核将 Bootloader 加载到内存中的 initramfs 中打包的文件解压到 rootfs 中，而这些文件中包含了驱动以及挂载真正的根文件系统的工具，内核通过加载这些驱动、使用这些工具，实现了挂载真正的根文件系统。此后，rootfs 也完成了历史使命，被真正的根文件系统覆盖（overmount）。但是 rootfs 作为虚拟文件系统目录树的总根，并不能被卸载。但是这没有关系，前面我们已经谈到了，rootfs 基于 ramfs，删除其中的文件即可释放其占用的空间
|
||||||
|
|
||||||
|
1、挂载 rootfs
|
||||||
|
用于不同操作系统的文件系统其物理存储结构是不同的，但是 Linux 的虚拟文件系统通过为这些文件系统建立中间适配层，实现了 Linux 对各个文件系统的支持，Linux 的虚拟文件系统将文件系统组织为树形结构。在初始化阶段，内核挂载 rootfs 文件系统，虚拟文件系统从无到有，rootfs 的根作为虚拟文件系统这棵大树中的第一个节点，自然成为所有后来创建的节点的祖先。也就是说，虚拟文件系统目录树的根就是 rootfs 的根，本质上，rootfs 就是一个 ramfs 文件系统。
|
||||||
|
通过挂载 rootfs，虚拟文件系统的根目录已经建立起来，根目录已经可以容纳文件了。所以，接下来内核解压 initramfs 的内容到虚拟文件系统的根中，利用 initramfs 中的内容挂载并切换到真正的根文件系统。
|
||||||
|
|
||||||
|
2、解压 initramfs 到 rootfs
|
||||||
|
在挂载了 rootfs 后，内核将 Bootloader 加载到内存中的 initramfs 中的文件解压到 rootfs 中。而这些文件中包含了驱动以及挂载真正的根文件系统的工具，内核通过加载这些驱动、使用这些工具实现挂载真正的根文件系统。
|
||||||
|
|
||||||
|
3、挂载并切换到真正的根目录
|
||||||
|
将 initramfs 成功解压后，挂载真正的根文件系统所需的驱动、程序等已经全部俱备，可以挂载真正的根文件系统了，在 grub.cfg 文件中对应的就是 root=XXX。内核将真正的根文件系统挂载到 initramfs 文件系统中的 /root 目录下。
|
||||||
|
挂载真正的根文件系统后，rootfs 中的内容已经没有保留的意义，但是并不能将 rootfs 卸载，因为 rootfs 是整个虚拟文件系统的根。因此，为了不占用内存空间，将 rootfs 中的内容（文件）释放掉即可，然后将真正的根文件系统移动到虚拟文件系统的根（即 rootfs 的根）下，最后再将进程的文件系统的 namespace 切换到真正的根文件系统。
|
||||||
|
|
||||||
|
# initramfs文件基本操作
|
||||||
|
1. 查看 initramfs
|
||||||
|
lsinitrd
|
||||||
|
|
||||||
|
2. 解压 initramfs
|
||||||
|
/usr/lib/dracut/skipcpio initramfs-3.10.0-229.el7.x86_64.img | zcat | cpio -ivd
|
||||||
|
|
||||||
|
3. 创建 initramfs
|
||||||
|
find . | cpio -o -H newc | gzip -9 > /tmp/test.img
|
||||||
304
计算机运作原理.md
Normal file
304
计算机运作原理.md
Normal file
@ -0,0 +1,304 @@
|
|||||||
|
# 启动
|
||||||
|
启动可以分为两种，一种为冷启动，是指计算机在关机状态下按 POWER 键启动，又叫硬件启动，比如开机，这种启动方式在启动之前计算机处于断电状态，像内存这种需要加电维持的存储部件里面的内容都丢失了，加电开机那一刻里面的值都是随机的，操作系统会对其进行初始化。
|
||||||
|
|
||||||
|
而热启动是在加电的情况下启动，又叫软件启动，比如重启，这种启动方式在启动之前和启动之后电没断过，内存等存储部件里面的值不会改变，但毕竟是启动过程，操作系统会对其进行初始化
|
||||||
|
|
||||||
|
不论是哪种启动，都会向 CPU 发送启动的信号，然后开始启动。同第一篇文章，我们分五个大的步骤讲述启动，BIOS -> MBR -> Bootloader -> OS -> Multiprocessor
|
||||||
|
|
||||||
|
系统 BIOS 所在的 ROM 是被设计成 CPU 可直接寻址的，而且地址范围也是固定的，从 0xF0000H 至 0xFFFFFH 共 64 KB。PC 按通电源后，电源设备开始向主板和其他设备供电，此时电压还不太稳定，主板上的控制芯片组会向 CPU 发出并保持一个 RESET（重置）信号，让 CPU 内部自动恢复到初始状态，但 CPU 在此刻不会马上执行指令。当芯片组检测到电源已经开始稳定供电了（当然从不稳定到稳定的过程只是一瞬间的事情），它便撤去 RESET 信号（如果是手工按下计算机面板上的 Reset 按钮来重启机器，那么松开该按钮时芯片组就会撤去 RESET 信号）CPU 进行重置，IP 寄存器的值设成 0，CS寄存器的值设成 0xFFFF。也就是说 CPU 马上从地址 0xFFFF0H 处开始执行指令，这个地址在系统 BIOS 空间的地址范围内，CPU 就是从这个固定的地址开始执行 BIOS 程序的。
|
||||||
|
|
||||||
|
各厂家的 BIOS 程序不尽相同，但基本都是完成 POST 自检及本地设备的枚举和初始化，包括对硬件执行一系列的测试，用来检测现在都有什么设备以及这些设备是否能正常工作，在这个阶段中，会显示一些信息，例如 BIOS 版本号等；初始化硬件设备，这个阶段在现代基于 PCI 的体系结构中相当重要，因为它可以保证所有的硬件设备操作不会引起 IRQ 线与 I/O 端口的冲突，在本阶段的最后，会显示系统中所安装的所有 PCI 设备的一个列表等。
|
||||||
|
|
||||||
|
BIOS 自检和初始化完成后，开始执行 BIOS 引导程序。由于系统 BIOS 空间只有 64KB 大小，把 Linux 内核放在这个空间里让 BIOS 引导程序直接引导是不可能的，只能把内核放在硬盘里（或其他设备，如 USB 或网络上， BIOS 根据启动顺序的设置依次查找），然后再从硬盘里引导 Linux 内核。但是，这时系统还处于实模式中，寻址能力只有 1MB，没有硬盘上的文件系统等信息，不会直接的引导整个 Linux 内核，而是通过先载入一个引导装入程序，然后由这个引导装入程序来引导 Linux 内核。
|
||||||
|
|
||||||
|
引导装入程序通常放在第一块硬盘（或其他设备）的第一个扇区里，这个扇区就是主引导扇区，包括硬盘主引导记录 MBR（Master Boot Record）、分区表DPT（Disk Partition Table）及主引导扇区标志 “55AA”，共 512 个字节。系统 BIOS 引导程序的唯一任务就是把存放在 MBR 中的引导装入程序载入内存的 0x7C00 位置（可以通过 BIOS 中断方式 INT 13h 读取磁盘指定扇区的内容），然后 CPU 跳转到这个地址，把控制权交给引导装入程序继续引导系统。GRUB（GRand Unified Bootloader）就是这样的一个引导程序。
|
||||||
|
|
||||||
|
# BIOS
|
||||||
|
启动的瞬间会将寄存器 CS 和 IP 初始化：CS = 0xf000, IP = 0xfff0。
|
||||||
|
|
||||||
|
刚启动的时候正处于实模式，实模式下地址总线只用了 20 位，只有 2^20 = 1M 的寻址空间，也就是只用到的内存的低 1M ，这个时候分页机制还没有建立起来，CPU 运行时的地址都是实际的物理地址。
|
||||||
|
|
||||||
|
但实模式下寄存器只用到了 16 位寄存器，如何使用寄存器来寻址 20 位的地址空间？Intel 采用分段的机制来访问内存，也就是采用 段基址 ：段偏移，
|
||||||
|
"地址 = 段基址 + 偏移量"的方式来访问，但是实模式下的寄存器只能使用 16 位，所以规定实模式下 "地址 = 段基址 X 16 + 偏移量" 。
|
||||||
|
因此根据 CS = 0xf000, IP = 0xfff0，得到的 address = 0xf000 << 4 + 0xfff0 = 0xffff0 。
|
||||||
|
|
||||||
|
这个地址是啥？ 来看内存低 1M 的内存布局：
|
||||||
|
|
||||||
|
| 起始 | 结束 | 大小 | 用途 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| FFFF0 | FFFFF | 16B | BIOS 入口地址，此地址也属于 BIOS 代码，同样属于顶部的 640 KB 字节，只是为了强调 其入口地址才单独贴出来。此处 16 字节的内容时跳转指令 jmp f000:e05b |
|
||||||
|
| F0000 | FFFEF | 64KB-16B | 系统 BIOS 范围是 F0000~FFFFF 共 640KB，为了说明入口地址，将最上面的 16 字节从此处去掉了，所以此处的终止地址是 0xFFFEF |
|
||||||
|
| C8000 | EFFFF | 160KB | 映射硬件适配器的 ROM 或内存映射模式 I/O |
|
||||||
|
| C0000 | C7FFF | 32KB | 显示适配器 BIOS |
|
||||||
|
| B8000 | BFFFF | 32KB | 用于文本模式显示适配器 |
|
||||||
|
| B0000 | B7FFF | 32KB | 用于黑白显示适配器 |
|
||||||
|
| A0000 | AFFFF | 64KB | 用于彩色显示适配器 |
|
||||||
|
| 9FC00 | 9FFFF | 1KB | EBDA (Extended BIOS Data Area) 扩展 BIOS 数据区 |
|
||||||
|
| 7E00 | 9FBFF | 622080B 约 608KB | 可用区域 |
|
||||||
|
| 7C00 | 7DFF | 512B | MBR 被 BIOS 加载到此处，共 512 字节 |
|
||||||
|
| 500 | 7BFF | 30464B 约 30KB | 可用区域 |
|
||||||
|
| 400 | 4FF | 256B | BIOS Data Area( BIOS 数据区 ) |
|
||||||
|
| 000 | 3FF | 1KB | Interrupt Vector Table ( 中断向量表 ) |
|
||||||
|
|
||||||
|
看最上面两行，可以知道 0xffff0 地址上存放的是一个跳转指令，CPU 执行这个命令然后跳转到 BIOS 代码的主体部分，BIOS 主要做一下几件事：
|
||||||
|
|
||||||
|
* 自检，然后对一些硬件设备做简单的初始化
|
||||||
|
* 构建中断向量表加载中断服务程序
|
||||||
|
* 将硬盘(通常引导设备就是硬盘)最开始那个扇区 MBR 加载到
|
||||||
|
|
||||||
|
# MBR
|
||||||
|
关于 MBR(Master Boot Record)，我在捋一捋磁盘及分区一文讲的比较详细了，这里不赘述，简单再说一下 MBR 的结构：
|
||||||
|
|
||||||
|
1. 引导程序和一些参数，446 字节
|
||||||
|
2. 分区表 DPT，64字节
|
||||||
|
3. 结尾标记签名，0x55 和 0xaa，两字节
|
||||||
|
|
||||||
|
MBR 的代码在分区表中寻找可以引导存在操作系统的分区，也就是寻找标记为 0x80 的活动分区，然后加载该活动分区的引导块，再执行其中的操作系统引导程序 Bootloader。
|
||||||
|
|
||||||
|
# Bootloader
|
||||||
|
Bootloader，操作系统引导程序，操作系统加载器，不论怎么叫，它的主要作用就是将操作系统加载到内存里面。操作系统也是一个程序，需要加载到内存里面才能运行。平常正在运行的计算机我们可以使用 exec 族函数来加载运行一个程序，同样的要加载运行操作系统这个程序就使用 Bootloader。
|
||||||
|
|
||||||
|
在 Bootloader 里面还做了一些其他事情，比如进入保护模式，开启分页机制，建立内存的映射等等。像 GRUB，U-Boot 等都属于 Bootloader，只是功能更多更强大。
|
||||||
|
|
||||||
|
# GRUB引导过程
|
||||||
|
|
||||||
|
GRUB（GRand Unified Bootloader）是一个多重启动管理器。它可以在多个操作系统共存时选择启动哪个系统，可以启动的操作系统包括Linux, FreeBSD, Solaris, NetBSD, BeOS, OS/2, Windows 95/98 /NT /2000。它可以载入操作系统的内核和初始化操作系统（如Linux, FreeBSD），或者把启动权交给操作系统（如Windows 98）来完成启动。
|
||||||
|
|
||||||
|
GRUB 的实质是一个 mini os，它拥有 shell，支持 script，支持特定文件系统等。GRUB 由 stage1，stage1_5，stage2 以及 /boot/grub 目录下的诸多文件（包括Grub的配置文件与相关文件系统定义文件等）组成。
|
||||||
|
|
||||||
|
stage1 被编译成了一个 512 字节的 img，写在硬盘的 0 面 0 道第 1 扇，它所做的唯一的事情就是装载第二引导装载程序 stage2。
|
||||||
|
|
||||||
|
stage1_5 写进了 MBR 后的 15 个扇区中（因为 e2fs_stage1_5 大小为 7.5k)。硬盘上第一个文件系统分区的开始扇区最小也只能从 0 柱面，1 磁头，1 扇区开始。就是说 MBR 所在 0 磁头就只用到了 1 个扇区而已（其它扇区都是未用的，不属于任何分区），按照现在硬盘的规格来说，一般一个柱面磁头都有 60+ 个扇区，所有将 stage1_5 写进 MBR 以后的扇区中，不会影响正常的文件系统分区。stage1_5 就是文件系统的解释代码，根据 /boot分区（或/boot所在分区）的具体文件系统类型而异，如：ext3 分区的话就是 e2fs_stage1_5。在 stage1_5 没有被加载以前，系统无法识别任何文件系统（但是可以通过 BIOS 中断方式 INT 13h 读取磁盘指定扇区的内容）, 加载 stage1_5 以后就可以识别 /boot所在分区的文件系统了，从而为加载 stage2 作好了准备。
|
||||||
|
|
||||||
|
stage2 是 grub 最核心的部分有 100 多KB，所以只能放在文件系统中，放在 /boot 分区里，放在这里的通常还有 Linux 内核映像文件。加载 stage2 后 grub 会根据 menulist 或用户输入加载 Linux 内核映像文件，即将内核映像装入地址 0x90000 的内存中，将内核入口装入到地址 0x90200 的内存中，然后跳转到内核入口处开始启动内核。
|
||||||
|
|
||||||
|
# OS
|
||||||
|
操作系统内核加载到内存之后，就做一些初始化工作建立好工作环境，比如各个硬件的初始化，重新设置 GDT，IDT 等等初始的操作。初始化启动其他处理器(如果有多个处理器的话)。这里不细说，也不好叙述，等下面直接看实例 xv6 做了哪些事，怎么做的。
|
||||||
|
|
||||||
|
# Multiprocessor
|
||||||
|
上述的启动过程是单处理情况下的启动过程，多处理器的情况下有些不同，用一句话先来简单概括多处理器情况下的启动：先启动一个 CPU，用它作为基础启动其他的处理器。
|
||||||
|
|
||||||
|
先启动的这个 CPU 称作 BSP(BootStrap Processor)，其他处理器叫做 AP(Application Processor)。BSP 是由系统硬件或者 BIOS 动态选择决定的。
|
||||||
|
|
||||||
|
多处理器启动过程大致分为以下几个大步骤：
|
||||||
|
|
||||||
|
1. BIOS 启动 BSP，流程与上述讲的 BIOS-MBR-bootloader-OS 差不多
|
||||||
|
2. BSP 从 MP Configuration Table 中获取多处理器的的配置信息
|
||||||
|
3. BSP 启动 APs，通过发送 INIT-SIPI-SIPI 消息给 APs
|
||||||
|
4. APs 启动，各个 APs 处理器要像 BSP 一样建立自己的一些机制，比如保护模式，分页，中断等等
|
||||||
|
|
||||||
|
这里我们主要关注第二点，获取多处理器的配置信息
|
||||||
|
|
||||||
|
# BSP启动详解
|
||||||
|
|
||||||
|
1. 在 BIOS POST 阶段，BSP 创建了 ACPI 表并添加它的 initial APIC ID。
|
||||||
|
2. 进到 OS 后，内核最开始的代码还是由 BSP 执行，初始化后进入正式的 SMP Boot 流程。
|
||||||
|
3. 在 BSP 执行后，将 processor 设置为 CPU 0 并广播一条 SIPI 消息给其他 AP，SIPI 消息包含了 BIOS AP 初始化的代码地址。
|
||||||
|
4. 第一个获得 SIPI 消息的 AP 获取 BIOS 初始化信号量，执行初始化代码，添加 APIC ID 并将 processor 加1，初始化结束后，AP 执行 CLI (Clear Interrupt Flag) 指令并 halt 自己。
|
||||||
|
5. 所有的 AP 都执行完初始化后，BSP 通过系统总线获取 processors 数量后，开始执行 OS boot-strap code、start-up code。AP 现在只能对 INITs, NMIs, and SMIs 响应，当然也响应 STPCLK# 引脚的 snoops、assertions
|
||||||
|
|
||||||
|
用一句话来概括多处理器情况下的启动：先启动一个 CPU，再以它为基础启动其他的处理器。
|
||||||
|
|
||||||
|
先启动的这个 CPU 称作 BSP(BootStrap Processor)，其他处理器叫做 AP(Application Processor)。硬件会动态选择系统总线上的一个 processor 作为 BSP，其余的为 AP。在计算机上电或者重置系统时，每个 CPU 都先执行处理器自检（BIST），自检通过的CPU就拥有了称为 BSP 的资格，那么此时选谁呢？
|
||||||
|
|
||||||
|
选择的方式为上电后所有的 CPU 都执行 NOP 指令，看看哪个 CPU 先发送了 NOP，就会成为 BSP，BSP 选出来之后，它会将 IA32_APIC_BASE MSR 里面的 BSP flag 设置为1，标识该处理器是 BSP，其他的APs进入 wait for SIPI 的状态，等待 BSP 的发号施令。
|
||||||
|
|
||||||
|
在 BIOS 中，BSP 首先要收集所有的 AP 信息，将所有 AP 信息登记下来，这个登记表称为 MP Configuration Table，它首先把自己加进去（CPU 0），然后让 APs 自己在登记表上登记。Processors 之间传递消息靠的是一种叫 Inter-Processor Interrupt（IPI）的机制，而通知登记在它们的语言里就是 SIPI(Start-up IPI )，当然 SIPI 只能由 BSP 来说才管用。
|
||||||
|
|
||||||
|
通常BSP的初始化顺序为：
|
||||||
|
|
||||||
|
1. 初始化内存。
|
||||||
|
2. 加载microcode
|
||||||
|
3. 初始化MTRRs
|
||||||
|
4. 初始化Cache
|
||||||
|
5. 加载 AP start-up code 到 1Mbyte 以下的 4K 内存中。
|
||||||
|
6. Enable APIC (SVR bit8）
|
||||||
|
7. Program ICR寄存器，把AP start-up code地址写到该寄存器
|
||||||
|
8. 在AP start-up code里,每个AP将会增加一个COUNT变量表示AP已经起来了
|
||||||
|
9. 广播INIT-SIPI-SIPI IPI sequence to the Aps,这时所有的AP才会真正被唤醒起来执行
|
||||||
|
|
||||||
|
https://zhuanlan.zhihu.com/p/598552628
|
||||||
|
https://peterhu.github.io/posts/2020/08/19/CPU%E5%A4%9A%E6%A0%B8%E5%88%9D%E5%A7%8B%E5%8C%96.html
|
||||||
|
|
||||||
|
# UP
|
||||||
|
UP（Uni-Processor）：系统只有一个处理器单元，即单核CPU系统。
|
||||||
|
|
||||||
|
# SMP
|
||||||
|
对称多处理器结构 , 英文名称为 " Symmetrical Multi-Processing " , 简称 SMP 。
|
||||||
|
SMP 又称为 UMA , 全称 " Uniform Memory Access " , 中文名称 " 统一内存访问架构 " 。
|
||||||
|
在 " 对称多处理器结构 " 的 系统中 , 所有的处理器单元的地位都是平等的 , 一般指的是服务器设备上 , 运行的 多个 CPU , 没有 主次/从属 关系，都是平等的。
|
||||||
|
这些处理器 共享 所有的设备资源 , 所有的资源对处理器单元具有相同的可访问性 , 如 : 磁盘 , 内存 , 总线等 ，多个CPU处理器共享相同的物理内存 , 每个 CPU 访问相同的物理地址 , 所消耗的时间是相同的 ;
|
||||||
|
要注意，这里提到的“处理器单元”是指“logic CPU”，而不是“physical CPU”。举个例子，如果一个“physical CPU”包含2个core，并且一个core包含2个hardware thread。则一个“处理器单元”就是一个hardware thread。
|
||||||
|
|
||||||
|
# 内核针对多处理器 CPU 下的调度
|
||||||
|
BIOS 调入执行启动引导区程序后，这段程序录入 Linux 操作系统的启动部分，解压缩 Linux 内核核心映像，然后转入 start_kernel 函数开始执行。在这以前，系统没有对 AP 做任何处理。在 start_kernel 函数中，主要处理例如 cache、内存等初始化工作，最后要调用 smp_init 函数，在这个函数里，具体实现 SMP 系统各 CPU 的初始处理机制, 我们来分析 smp_init 函数
|
||||||
|
在 [linux/init/main.c] 中
|
||||||
|
|
||||||
|
~~~c
|
||||||
|
static void __init smp_init(void)
|
||||||
|
{
|
||||||
|
smp_boot_cpus();
|
||||||
|
smp_threads_ready=1;
|
||||||
|
smp_commence();
|
||||||
|
}
|
||||||
|
~~~
|
||||||
|
|
||||||
|
在函数 smp_boot_cpus 中，要建立并初始化各 AP，关键代码如下：
|
||||||
|
在 [linux/arch/i386/kernel/smpboot.c] 中
|
||||||
|
~~~C
|
||||||
|
void __init smp_boot_cpus(void)
|
||||||
|
{
|
||||||
|
……
|
||||||
|
for (apicid = 0; apicid < NR_CPUS; apicid++) {
|
||||||
|
if (apicid == boot_cpu_id)
|
||||||
|
continue; // 是BP，因为上面已经初始化完毕，就不再需要初始化
|
||||||
|
|
||||||
|
if (!(phys_cpu_present_map & (1 << apicid)))
|
||||||
|
continue; // 如果CPU不存在，不需要初始化
|
||||||
|
|
||||||
|
if ((max_cpus >= 0) && (max_cpus <= cpucount+1))
|
||||||
|
continue; //如果超过最大支持范围，不需要初始化
|
||||||
|
|
||||||
|
do_boot_cpu(apicid);// 对每个AP调用do_boot_cpu函数
|
||||||
|
……
|
||||||
|
}
|
||||||
|
……
|
||||||
|
}
|
||||||
|
~~~
|
||||||
|
|
||||||
|
下面我们看一下do_boot_cpu中做了什么工作：
|
||||||
|
在[linux/arch/i386/kernel/smpboot.c]中
|
||||||
|
~~~c
|
||||||
|
static void __init do_boot_cpu (int apicid)
|
||||||
|
{
|
||||||
|
struct task_struct *idle; // 空闲进程结构
|
||||||
|
……
|
||||||
|
if (fork_by_hand() < 0) //在每个cpu上建立0号进程，这些进程共享内存
|
||||||
|
……
|
||||||
|
idle->thread.eip = (unsigned long) start_secondary;
|
||||||
|
// 将空闲进程结构的eip设置为 start_secondary 函数的入口处
|
||||||
|
……
|
||||||
|
start_eip = setup_trampoline(); // 得到trampoline.S代码的入口地址
|
||||||
|
stack_start.esp = (void *) (1024 + PAGE_SIZE + (char *)idle);
|
||||||
|
……
|
||||||
|
*((volatile unsigned short *) phys_to_virt(0x469)) = start_eip >> 4;
|
||||||
|
Dprintk("2.\n");
|
||||||
|
*((volatile unsigned short *) phys_to_virt(0x467)) = start_eip & 0xf;
|
||||||
|
Dprintk("3.\n");
|
||||||
|
// 将trampoline.S的入口地址写入热启动的中断向量(warm reset vector)40:67
|
||||||
|
……
|
||||||
|
apic_write_around(APIC_ICR2, SET_APIC_DEST_FIELD(apicid));
|
||||||
|
// 确定发送对象
|
||||||
|
apic_write_around(APIC_ICR, APIC_INT_LEVELTRIG | APIC_DM_INIT);
|
||||||
|
// 发送INIT IPI
|
||||||
|
……
|
||||||
|
apic_write_around(APIC_ICR2, SET_APIC_DEST_FIELD(apicid));
|
||||||
|
//确定发送对象
|
||||||
|
apic_write_around(APIC_ICR, APIC_DM_STARTUP | (start_eip >> 12));
|
||||||
|
//发送STARTUP IPI
|
||||||
|
……
|
||||||
|
}
|
||||||
|
~~~
|
||||||
|
|
||||||
|
现在对上面初始设置做如下概括 [1]：
|
||||||
|
BSP 将 AP 在一开始被唤醒后需要执行的代码（trampoline.S）的首地址写入热启动向量（warm reset vector
|
||||||
|
），即从40:67开始的两个字。这样，当 BSP 对 AP 发送 IPI 时，AP 响应中断，自动跳入这个 trampoline.S 代码
|
||||||
|
部分继续执行。为了 AP 有足够的时间响应中断，BSP 在发送中断请求后要延迟一段时间，。
|
||||||
|
在这以后，事实上 AP 已经在工作了，我们跟随 AP，看它在做什么。AP 响应中断直接跳转至 trampoline.S 的
|
||||||
|
入口处，trampoline.S 在载入符号表 (gdt) 和局部符号表 (ldt) 之后进入保护模式并跳至 head.S 的入口处：
|
||||||
|
在 [linux/arch/i386/kernel/trampoline.S] 中
|
||||||
|
~~~C
|
||||||
|
……
|
||||||
|
inc %ax #protected mode (PE) bit
|
||||||
|
lmsw %ax # 进入保护模式
|
||||||
|
jmp flush_instr
|
||||||
|
flush_instr:
|
||||||
|
ljmpl $__KERNEL_CS, $0x00100000
|
||||||
|
# 一个长跳转，0x10:0x00100000是内核被解压后的起始地址，即 head.S 的 startup_32[7]
|
||||||
|
……
|
||||||
|
~~~
|
||||||
|
|
||||||
|
AP 转入 head.S 继续执行，但是执行的代码与 BSP 所执行的并不完全一致：
|
||||||
|
在 [linux/arch/i386/kernel/head.S] 中
|
||||||
|
~~~C
|
||||||
|
ENTRY(stext)
|
||||||
|
ENTRY(_stext)
|
||||||
|
startup_32:
|
||||||
|
……
|
||||||
|
incb ready # 该段代码每执行一次，ready 值加 1，BSP 执行时 ready 的值从 0 变为 1
|
||||||
|
……
|
||||||
|
movb ready, %cl
|
||||||
|
cmpb $1,%cl
|
||||||
|
je 1f # 当执行 CPU 为 BSP 时，ready 的值为 1
|
||||||
|
call SYMBOL_NAME(initialize_secondary) # 执行 initialize_secondary 函数
|
||||||
|
jmp L6
|
||||||
|
1:
|
||||||
|
call SYMBOL_NAME(start_kernel) # 执行 start_kernel() 函数
|
||||||
|
L6:
|
||||||
|
jmp L6
|
||||||
|
ready: .byte 0 # ready 为字节变量，初始值为 0
|
||||||
|
~~~
|
||||||
|
|
||||||
|
AP 执行 head.S 的过程是当执行到上述代码的时候，由于 ready 的值被改变，不再等于 1，所以就继续向前执行
|
||||||
|
，调用 initialize_secondary 函数，而不是像 BSP 一样执行标号 1 处的代码（调用start_kernel函数）。
|
||||||
|
initialize_secondary 函数里面的代码很简单：
|
||||||
|
在 [linux/arch/i386/kernel/smpboot.c] 中
|
||||||
|
~~~c
|
||||||
|
void __init initialize_secondary(void)
|
||||||
|
{
|
||||||
|
asm volatile(
|
||||||
|
"movl %0,%%esp\n\t"
|
||||||
|
"jmp *%1"
|
||||||
|
:
|
||||||
|
:"r" (current->thread.esp),"r" (current->thread.eip));
|
||||||
|
}
|
||||||
|
~~~
|
||||||
|
|
||||||
|
这是一段内嵌汇编程序，将程序跳转至 current->thread.esp（即前面的idle->thread.esp）处 [8]。CPU执
|
||||||
|
行 start_secondary 函数，进入空闲状态。
|
||||||
|
在 [linux/arch/i386/kernel/smpboot.c] 中
|
||||||
|
~~~c
|
||||||
|
int __init start_secondary(void *unused)
|
||||||
|
{
|
||||||
|
cpu_init();
|
||||||
|
smp_callin();
|
||||||
|
while (!atomic_read(&smp_commenced))
|
||||||
|
rep_nop();
|
||||||
|
local_flush_tlb();
|
||||||
|
return cpu_idle(); // 进入空闲进程
|
||||||
|
}
|
||||||
|
~~~
|
||||||
|
|
||||||
|
至此，一个 AP 的初始化过程就完成了。
|
||||||
|
|
||||||
|
总结
|
||||||
|
下面简要的再把Linux的SMP启动过程做一总结。
|
||||||
|
在 SMP 中，首先要对各个处理器进行初始化。然后 BSP 工作，而其它的 CPU（AP）则停留在一个初始化好的
|
||||||
|
中断屏蔽状态休眠。BSP 继续进行启动过程，在执行到操作系统的 start_kernel 之前，BSP 所进行的工作与单
|
||||||
|
处理器系统所做的工作是相同的。在 start_kernel 中，BSP 通过 smp_init 对每个 AP 进行初始化。初始化的
|
||||||
|
方式是通过 APIC 发送 IPI。当 BSP 初始化完毕所有的 AP 之后，就继续执行 start_kernel 中的其余部分代码。
|
||||||
|
而 AP 在接收到 IPI 之后，跳转到事先设置好的地址处执行 trampoline.S 和 head.S。在执行 head.S 的过程中
|
||||||
|
直接跳入事先创建好的空闲进程，进入空闲状态，等待以后的系统调度。
|
||||||
|
|
||||||
|
内核调度
|
||||||
|
在 [kernel/sched.c] 中, 内核为每一颗 CPU 分配了一个 runqueue ，我们的线程驱动就是每个 CPU 调用此队列的任务进行执行驱动
|
||||||
|
|
||||||
|
# 内核是怎么知道各个硬件的信息的？
|
||||||
|
答案就是通过 SMBios 表，此表由 UEFI 或者 Legacy BIOS 提供的, 从 SMBIOS 的 spec 中可以看到，对于基于 Legacy BIOS 的系统而言，系统软件可以通过在物理内存范围 000F0000h ～ 000FFFFFh 内搜索制定的字符串来定位到 SMBIOS 表的入口点。对于SMBIOS 2.1 而言，这个字符串是 "_SM_"，对于 SMBIOS 3.0 而言，这个字符串为 "_SM3_"。
|
||||||
|
|
||||||
|
而对于基于 UEFI 的系统而言，EFI configuration table (EFI_CONFIGURATION_TABLE) 包含了指向 SMBIOS table 的指针。
|
||||||
|
|
||||||
|
|
||||||
|
每个硬件方法不同。比如说内存，内存条上有一个 smbus 总线的 eeprom，记录内存条的信息。usb 总线的总线协议就规定了设备类型，如存储设备，输入设备等。pcie 总线有 vendor id, device id. 板上一些无法通过枚举过程识别的，可能会硬编码在 BIOS 里，因为每个主板都要研发一次 BIOS。BIOS 和内核传递信息有多种标准。acpi, device tree 之类的。有些设备内核还会自己枚举，不用 BIOS 告诉他。
|
||||||
|
|
||||||
|
|
||||||
|
# 内核线程的实现
|
||||||
|
https://segmentfault.com/a/1190000040253849
|
||||||
|
|
||||||
|
# 锁的实现
|
||||||
|
特别注意锁的悬停 ( mutex 的实现原理 )
|
||||||
|
所有的锁的机制都是类似于“自旋锁”的机制，mutex 也不例外，当然会阻塞，是因为加锁失败，会把当前线程加入等待队列，把当前线程加入等待队列，等待下一轮的锁的抢占，抢占到锁，线程继续执行，否则还得继续等待，而对应的 CPU 线程，可没闲着继续驱动内核线程执行，对于用户层来说，仿佛多个线程在不停的执行。
|
||||||
|
https://segmentfault.com/a/1190000040360086
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user