第一章：应用程序与基本执行环境

• APP调用OS service而不是直接与M-Mode的模块进行交互

• 整个程序的App部分和OS部分的镜像会被加载到内存中

应用程序执行环境与平台支持

• 环境并不是绝对的，上层程序的环境就是下层程序

• 黑色块表示相邻两层执行环境的接口

• 系统调用充当了用户和内核之间的边界

• 除了最上层的应用程序和最下层的硬件平台必须存在之外，作为中间层的函数库和操作系统内核并不是必须存在的

• 处理器 (Processor，也称CPU)，内存 (Memory) 还有 I/O 设备。其中处理器无疑是其中最复杂，同时也最关键的一个。它与软件约定一套 指令集体系结构 (ISA, Instruction Set Architecture)，使得软件可以通过 ISA 中提供的机器指令来访问各种硬件资源
• 如果ISA不同，同一个语言生成的可执行文件可能不同——跨平台

• Rust编译器通过 目标三元组 (Target Triplet) 来描述一个软件运行的目标平台，它一般包括 CPU、操作系统和运行时库等信息



host字段：
• CPU架构是x86_64
• CPU厂商unknown
• 操作系统是Linux
• 运行时库是GNU libc

• rustc --print target-list| grep riscv

• riscv32gc-unknown-linux-gnu

• riscv32i-unknown-none-elf

• riscv32imac-unknown-none-elf

• riscv32imc-unknown-none-elf

• riscv64gc-unknown-linux-gnu

• riscv64gc-unknown-none-elf——本实验需要的平台，裸机运行，不需要标准运行时库

• riscv64imac-unknown-none-elf

• 交叉编译 (Cross Compile)

移除标准库依赖

• #![no_std]
告诉 Rust 编译器不使用 Rust 标准库 std 转而使用核心库 core（core库不需要操作系统的支持）

• #![no_main]
告诉编译器我们没有一般意义上的 main 函数，并将原来的 main 函数删除

内核第一条指令

• 安装

• 运行

• 进入第一阶段
[GDB output] 0x0000000000001000 in ?? ()
将必要的文件载入到 Qemu 物理内存之后，Qemu CPU 的程序计数器（PC, Program Counter）会被初始化为 0x1000，因此 Qemu 实际执行的第一条指令位于物理地址 0x1000 ，接下来它将执行寥寥数条指令并跳转到物理地址 0x80000000 对应的指令处并进入第二阶段
• 查看程序计数器所指的指令和之后的10条指令
可以看出从1014开始，后面的指令都是unimp，说明只有前5条指令是Qemu固件所包含的指令。执行到1010时，t0里面恰好是0x80000000，这样就可以直接跳转到到该地址执行我们自己编写的指令

• 进入第二阶段
由于 Qemu 的第一阶段固定跳转到 0x80000000 ，我们需要将负责第二阶段的 bootloader rustsbi-qemu.bin 放在以物理地址 0x80000000 开头的物理内存中，这样就能保证 0x80000000 处正好保存 bootloader 的第一条指令。在这一阶段，bootloader 负责对计算机进行一些初始化工作，并跳转到下一阶段软件的入口，在 Qemu 上即可实现将计算机控制权移交给我们的内核镜像 os.bin 。

• 进入第三阶段
我们选用的 RustSBI 则是将下一阶段的入口地址预先约定为固定的 0x80200000 ，在 RustSBI 的初始化工作完成之后，它会跳转到该地址并将计算机控制权移交给下一阶段的软件——也即我们的内核镜像。一旦 CPU 开始执行内核的第一条指令，证明计算机的控制权已经被移交给我们的内核，也就达到了本节的目标。



可以看到程序成功停在了设定好的0x80200000处

为内核支持函数调用

• 第一条表示jump and link，将当前指令的下一条指令放入rd，跳转目标地址是相对于pc指向的地址的

• 第二条表示jump and link register，将当前指令的下一条指令放入rd，跳转目标地址是相对于寄存器 rs 指向的地址的

• rs 表示 源寄存器 (Source Register)， imm 表示 立即数 (Immediate)，是一个常数，二者构成了指令的输入部分；而 rd 表示 目标寄存器 (Destination Register)，它是指令的输出部分。rs 和 rd 可以在 32 个通用寄存器 x0~x31 中选取。
通常使用 ra 寄存器（即 x1 寄存器）作为其中的 rd 对应的具体寄存器，因此在函数返回的时候，只需跳转回 ra 所保存的地址即可。

• 在进行函数调用的时候，我们通过 jalr 指令保存返回地址并实现跳转；而在函数即将返回的时候，则通过 ret 伪指令回到跳转之前的下一条指令继续执行

• 分配了4096*16字节，也就是64KiB的空间用作接下来要运行的程序的栈空间

• 在 RISC-V 架构上，栈是从高地址向低地址增长

• 在进入主函数之前 分配好栈空间

• 对于范围中的每个地址 a，使用 for_each 方法执行一个闭包操作。这个闭包使用 unsafe 代码，因为它直接操作了内存。

• (a as *mut u8) 将地址 a 转换为一个可变指针，因为按字节编码，需要逐字节对bss段清零

• write_volatile(0) 将地址 a 指向的内存空间写入值 0

第二章：批处理系统

特权级机制

• 应用程序不能访问任意的地址空间（这个在第四章会进一步讲解，本章不会涉及）

• 应用程序不能执行某些可能破坏计算机系统的指令（本章的重点）

• ecall 具有用户态到内核态的执行环境切换能力的函数调用指令；

• sret ：具有内核态到用户态的执行环境切换能力的函数返回指令。

• 应用程序在U模式

• kernel在S模式

• 而第一章提到的预编译的 bootloader – RustSBI 实际上是运行在更底层的 M 模式特权级下的软件，是操作系统内核的执行环境

• 执行环境要对上层运行的程序进行监控和管理

• 上层程序出错后，需要运行执行环境中的代码对错误进行处理——CPU特权级切换

• 而执行环境中的代码运行完毕，就要回到上层被中断的地方继续执行，这种控制流就叫异常控制流ECF，是RISC-V语境下的 Trap 种类之一

• 其中 断点 (Breakpoint) 和 执行环境调用 (Environment call) 两种异常（为了与其他非有意为之的异常区分，会把这种有意为之的指令称为 陷入 或 trap 类指令，此处的陷入为操作系统中传统概念）是通过在上层软件中执行一条特定的指令触发的：执行 ebreak 这条指令之后就会触发断点陷入异常；而执行 ecall 这条指令时候则会随着 CPU 当前所处特权级而触发不同的异常

• M 模式软件 SEE 和 S 模式的内核之间的接口被称为 监督模式二进制接口 (Supervisor Binary Interface, SBI)

• 而内核和 U 模式的应用程序之间的接口被称为 应用程序二进制接口 (Application Binary Interface, ABI)，当然它有一个更加通俗的名字—— 系统调用 (syscall, System Call) 

• 是机器/汇编指令级的一种接口

实现应用程序

• inlateout("x10") args[0] => ret 表示 x10 寄存器在汇编代码开始执行前，其值被设置为 args[0]，并且在汇编代码执行完成后，x10 寄存器的值被存储到 ret 变量中

• in("x11") args[1], 和 in("x12") args[2],：这两行是传递系统调用的参数到相应的寄存器中

• in("x17") id：这行是将系统调用号传递给寄存器 x17，以便进行系统调用

• 在第一章中，我们曾经使用 global_asm! 宏来嵌入全局汇编代码，而这里的 asm! 宏可以将汇编代码嵌入到局部的函数上下文中。相比 global_asm! ， asm! 宏可以获取上下文中的变量信息并允许嵌入的汇编代码对这些变量进行操作。由于编译器的能力不足以判定插入汇编代码这个行为的安全性，所以我们需要将其包裹在 unsafe 块中自己来对它负责。 第一章是：

实现批处理操作系统

• 保存应用数量和各自的位置信息，以及当前执行到第几个应用了。

• 根据应用程序位置信息，初始化好应用所需内存空间，并加载应用执行。

应用管理器 AppManager 结构体定义如下：

• num_app：应用程序的数量

• current_app：当前执行到哪个应用程序了

• app_start：应用程序的开始地址，最后一个应用程序要标记结束地址

• 我们希望将 AppManager 实例化为一个全局变量，使得任何函数都可以直接访问，又希望可以修改它

• 使用RefCell

• 它提供了在不可变引用（&T）的基础上进行内部可变性的机制，允许在不违反 Rust 的借用规则的前提下，在运行时进行可变性检查

• 实现UPSafeCell的线程安全特征并标记它为unsafe

• 因为目前我们的程序只在单核上运行，且RefCell的可变性检查保证只有一个可变借用存在

• 当我们要访问数据时（无论读还是写），需要首先调用 exclusive_access 获得数据的可变借用标记，通过它可以完成数据的读写，在操作完成之后我们需要销毁这个标记，此后才能开始对该数据的下一次访问

• 相比 RefCell 它不再允许多个读操作同时存在

• 依靠RefCell提供的可变性检查，当使用者违背了上述模式，比如访问之后忘记销毁就开启下一次访问时，程序会 panic 并退出

构建名为APP_MANAGER的全局结构体变量：

• lazy_static! 宏提供了全局变量的运行时初始化功能。一般情况下，全局变量必须在编译期设置初始值， 但是有些全局变量的初始化依赖于运行期间才能得到的数据。 如这里我们借助 lazy_static! 声明了一个 AppManager 结构的名为 APP_MANAGER 的全局实例， 只有在它第一次被使用到的时候才会进行实际的初始化工作

• extern "C" { fn _num_app(); }
这段语句表示：声明一个外部函数 _num_app。这个 extern 块告诉 Rust 编译器，在当前作用域中存在一个名为 _num_app 的外部函数，但是其具体的实现并不在 Rust 代码中，而是由其他地方提供，通常是由汇编语言或者其他语言实现
link_app.S是一个汇编语言文件，其中包含了 _num_app 这个符号的实现。通常情况下，汇编或者其他语言实现的函数会在链接过程中与 Rust 代码进行链接，从而形成最终的可执行文件或者库文件

• let num_app_ptr = _num_app as usize as *const usize;
构建一个指向该符号的指针
• 该指针当前指向app的数量
• 后面是每个app的起始地址，最后一个app有结束地址，因此后面的代码：
表示：创建一个名为 app_start_raw 的不可变引用，指向从 num_app_ptr.add(1) 开始，长度为 num_app + 1 的连续内存块。这个切片是从指针 num_app_ptr 的下一个元素开始，长度为 num_app + 1。

• 然后应该把它们装进数组app_start

AppManager 的方法

• pub fn print_app_info(&self)
打印出总共的app数量和每个app的起始地址和结束地址

• unsafe fn load_app(&self, app_id: usize)
这个方法负责将参数 app_id 对应的应用程序的二进制镜像加载到物理内存以 0x80400000 起始的位置
首先将一块内存清空，然后找到待加载应用二进制镜像的位置，并将它复制到正确的位置。它本质上是把数据从一块内存复制到另一块内存，从批处理操作系统的角度来看，是将操作系统数据段的一部分数据（实际上是应用程序）复制到了一个可以执行代码的内存区域

大致流程

实现特权级的切换

RISC-V特权级切换

• 当启动应用程序的时候，需要初始化应用程序的用户态上下文，并能切换到用户态执行应用程序；

• 当应用程序发起系统调用（即发出 Trap）之后，需要到批处理操作系统中进行处理；

• 当应用程序执行出错的时候，需要到批处理操作系统中杀死该应用并加载运行下一个应用；

• 当应用程序执行结束的时候，需要到批处理操作系统中加载运行下一个应用（实际上也是通过系统调用 sys_exit 来实现的）。

• 当 CPU 在用户态特权级（ RISC-V 的 U 模式）运行应用程序，执行到 Trap，切换到内核态特权级（ RISC-V的S 模式）

• 批处理操作系统的对应代码响应 Trap，并执行系统调用服务

• 处理完毕后，从内核态返回到用户态应用程序继续执行后续指

特权级切换的硬件控制机制

• sstatus 的 SPP 字段会被修改为 CPU 当前的特权级（U/S）。

• sepc 会被修改为 Trap 处理完成后默认会执行的下一条指令的地址。

• scause/stval 分别会被修改成这次 Trap 的原因以及相关的附加信息。

• CPU 会跳转到 stvec 所设置的 Trap 处理入口地址，并将当前特权级设置为 S ，然后从Trap 处理入口地址处开始执行。

用户栈与内核栈

• 由于通用寄存器在用户态和内核态都需要被使用，很难判断哪些寄存器变了哪些寄存器没变，因此干脆保存32个寄存器

• 对于 CSR 而言，我们知道进入 Trap 的时候，硬件会立即覆盖掉 scause/stval/sstatus/sepc 的全部或是其中一部分。scause/stval 的情况是：它总是在 Trap 处理的第一时间就被使用或者是在其他地方保存下来了，因此它没有被修改并造成不良影响的风险。而对于 sstatus/sepc 而言，它们会在 Trap 处理的全程有意义（在 Trap 控制流最后 sret 的时候还用到了它们），而且确实会出现 Trap 嵌套的情况使得它们的值被覆盖掉。所以我们需要将它们也一起保存下来，并在 sret 之前恢复原样

Trap 管理

• 应用程序通过 ecall 进入到内核状态时，操作系统保存被打断的应用程序的 Trap 上下文；

• 操作系统根据Trap相关的CSR寄存器内容，完成系统调用服务的分发与处理；

• 操作系统完成系统调用服务后，需要恢复被打断的应用程序的Trap 上下文，并通 sret 让应用程序继续执行。

• MODE 位于 [1:0]，长度为 2 bits；

• BASE 位于 [63:2]，长度为 62 bits。

• 首先通过 __alltraps 将 Trap 上下文保存在内核栈上

• 然后跳转到使用 Rust 编写的 trap_handler 函数完成 Trap 分发及处理

• 当 trap_handler 返回之后，使用 __restore 从保存在内核栈上的 Trap 上下文恢复寄存器。最后通过一条 sret 指令回到应用程序执行。

保存Trap上下文__alltraps:

• x0~x31 x0 到 x31 是通用寄存器，用于存储数据或地址。其中，x0 通常被称为零寄存器（zero register），始终为零，不可被写入。

• t0~t2
t0 到 t2 也是通用寄存器，用于临时存储数据。它们在 RISC-V 规范中没有具体的用途，通常用于临时变量的存储或者用作数据传递的中间寄存器

• a0~a7
a0 到 a7 是参数寄存器，用于函数参数的传递。在函数调用时，调用者将参数存储在这些寄存器中，然后被调用函数可以在其中读取参数

恢复Trap上下文__restore:

Trap 分发与处理

• 触发 Trap 的原因是来自 U 特权级的 Environment Call，也就是系统调用
将sepc的值+4，因为ecall是进入Trap前执行的最后一条语句，此时sepc的值是这条语句的地址，而现在希望Trap的操作完成后返回用户态时，从ecall的下一条指令继续执行程序。因此我们只需修改 Trap 上下文里面的 sepc，让它增加 ecall 指令的码长，也即 4 字节
这样在 __restore 的时候 sepc 在恢复之后就会指向 ecall 的下一条指令，并在 sret 之后从那里开始执

• 后面几行分别处理应用程序出现访存错误和非法指令错误的情形。此时需要打印错误信息并调用 run_next_app 直接切换并运行下一个应用程序

• _的情形：当遇到目前还不支持的 Trap 类型的时候，“邓式鱼” 批处理操作系统整个 panic 报错退出

执行应用程序

• 构造应用程序开始执行所需的 Trap 上下文；

• 通过 __restore 函数，从刚构造的 Trap 上下文中，恢复应用程序执行的部分寄存器；

• 设置 sepc CSR的内容为应用程序入口点 0x80400000；

• 切换 scratch 和 sp 寄存器，设置 sp 指向应用程序用户栈；

• 执行 sret 从 S 特权级切换到 U 特权级。

• 我们只需要在内核栈上压入一个为启动应用程序而特殊构造的 Trap 上下文，再通过 __restore 函数，就能让这些寄存器到达启动应用程序所需要的上下文状态

• sp←a0让sp指向新的栈顶，此时栈顶是这个特殊的Trap上下文

总的流程