...
[kernel] num_app = 5
[kernel] app_0 [0x8020a038, 0x8020af90)
...
[kernel] Loading app_0
Hello, world!
[kernel] Application exited with code 0
[kernel] Loading app_1
...
[kernel] Panicked at src/batch.rs:58 All applications completed!
构建应用:把多个应用合在一起与OS形成一个二进制镜像
├── os
│ ├── build.rs(新增:生成 link_app.S 将应用作为一个数据段链接到内核)
│ ├── Cargo.toml
│ ├── Makefile(修改:构建内核之前先构建应用)
│ └── src
│ ├── link_app.S(构建产物,由 os/build.rs 输出)
改进OS:加载和执行程序、特权级上下文切换
├── os
│ └── src
│ ├── batch.rs(新增:实现了一个简单的批处理系统)
│ ├── main.rs(修改:主函数中需要初始化 Trap 处理并加载和执行应用)
│ └── trap(新增:Trap 相关子模块 trap)
│ ├── context.rs(包含 Trap 上下文 TrapContext)
│ ├── mod.rs(包含 Trap 处理入口 trap_handler)
│ └── trap.S(包含 Trap 上下文保存与恢复的汇编代码)
改进OS:系统调用
├── os
│ └── src
│ ├── syscall(新增:系统调用子模块 syscall)
│ │ ├── fs.rs(包含文件 I/O 相关的 syscall)
│ │ ├── mod.rs(提供 syscall 方法根据 syscall ID 进行分发处理)
│ │ └── process.rs(包含任务处理相关的 syscall)
添加应用:批处理OS会按照文件名开头的数字顺序依次加载并运行它们
└── user(新增:应用测例保存在 user 目录下)
└── src
├── bin(基于用户库 user_lib 开发的应用,每个应用放在一个源文件中)
│ ├── 00hello_world.rs # 显示字符串的应用
│ ├── 01store_fault.rs # 非法写操作的应用
│ ├── 02power.rs # 计算/IO频繁交替的应用
│ ├── 03priv_inst.rs # 执行特权指令的应用
│ └── 04priv_csr.rs # 执行CSR操作指令的应用
应用库和编译应用支持
└── user(新增:应用测例保存在 user 目录下)
└── src
├── console.rs # 支持println!的相关函数与宏
├── lang_items.rs # 实现panic_handler函数
├── lib.rs(用户库 user_lib) # 应用调用函数的底层支撑库
├── linker.ld # 应用的链接脚本
└── syscall.rs(包含 syscall 方法生成实际用于系统调用的汇编指令,
各个具体的 syscall 都是通过 syscall 来实现的)
RISC-V 陷入(trap)类指令
RISC-V 特权指令
RISC-V异常向量
Interrupt | Exception Code | Description |
---|---|---|
0 | 0 | Instruction address misaligned |
0 | 1 | Instruction access fault |
0 | 2 | Illegal instruction |
0 | 3 | Breakpoint |
0 | 4 | Load address misaligned |
0 | 5 | Load access fault |
RISC-V异常向量
Interrupt | Exception Code | Description |
---|---|---|
0 | 6 | Store/AMO address misaligned |
0 | 7 | Store/AMO access fault |
0 | 8 | Environment call from U-mode |
0 | 9 | Environment call from S-mode |
0 | 11 | Environment call from M-mode |
RISC-V异常向量
Interrupt | Exception Code | Description |
---|---|---|
0 | 12 | Instruction page fault |
0 | 13 | Load page fault |
0 | 15 | Store/AMO page fault |
核心是如何写底层支撑库
└── user(应用程序和底层支撑库)
└── src
├── bin(该目录放置基于用户库 user_lib 开发的应用)
├── lib.rs(用户库 user_lib) # 库函数的底层支撑库
├── ...... # 支撑库相关文件
└── linker.ld # 应用的链接脚本
引入外部库
#[macro_use]
extern crate user_lib;
在 lib.rs 中我们定义了用户库的入口点 _start :
#[no_mangle]
#[link_section = ".text.entry"]
pub extern "C" fn _start() -> ! {
clear_bss();
exit(main());
panic!("unreachable after sys_exit!");
}
user/src/linker.ld
其余的部分与之前相同
ecall
指令会触发 名为 Environment call from U-mode 的异常/// 功能:将内存中缓冲区中的数据写入文件。
/// 参数:`fd` 表示待写入文件的文件描述符;
/// `buf` 表示内存中缓冲区的起始地址;
/// `len` 表示内存中缓冲区的长度。
/// 返回值:返回成功写入的长度。
/// syscall ID:64
fn sys_write(fd: usize, buf: *const u8, len: usize) -> isize;
/// 功能:退出应用程序并将返回值告知批处理系统。
/// 参数:`xstate` 表示应用程序的返回值。
/// 返回值:该系统调用不应该返回。
/// syscall ID:93
fn sys_exit(xstate: usize) -> !;
fn syscall(id: usize, args: [usize; 3]) -> isize {
let mut ret: isize;
unsafe {
asm!(
"ecall",
inlateout("x10") args[0] => ret, //第一个参数&返回值
in("x11") args[1], //第二个参数
in("x12") args[2], //第三个参数
in("x17") id //syscall编号
);
}
ret //返回值
}
const SYSCALL_WRITE: usize = 64;
const SYSCALL_EXIT: usize = 93;
//对系统调用的封装
pub fn sys_write(fd: usize, buffer: &[u8]) -> isize {
syscall(SYSCALL_WRITE, [fd, buffer.as_ptr() as usize, buffer.len()])
}
pub fn sys_exit(xstate: i32) -> isize {
syscall(SYSCALL_EXIT, [xstate as usize, 0, 0])
}
pub fn write(fd: usize, buf: &[u8]) -> isize { sys_write(fd, buf) }
const STDOUT: usize = 1;
impl Write for Stdout {
fn write_str(&mut self, s: &str) -> fmt::Result {
write(STDOUT, s.as_bytes());
Ok(())
}
}
# os/src/link_app.S 由脚本 os/build.rs 生成
.section .data
.global _num_app
_num_app:
.quad 5
.quad app_0_start
...
.quad app_4_end
.section .data
.global app_0_start
.global app_0_end
app_0_start:
.incbin "../user/target/riscv64gc-unknown-none-elf/release/00hello_world.bin"
app_0_end:
// os/src/batch.rs
struct AppManager {
num_app: usize,
current_app: usize,
app_start: [usize; MAX_APP_NUM + 1],
}
lazy_static! {
static ref APP_MANAGER: UPSafeCell<AppManager> = unsafe { UPSafeCell::new({
extern "C" { fn _num_app(); }
let num_app_ptr = _num_app as usize as *const usize;
...
app_start[..=num_app].copy_from_slice(app_start_raw);
AppManager {
num_app,
current_app: 0,
app_start,
}
unsafe fn load_app(&self, app_id: usize) {
// clear icache
asm!("fence.i");
// clear app area
...
let app_src = core::slice::from_raw_parts(
self.app_start[app_id] as *const u8,
self.app_start[app_id + 1] - self.app_start[app_id] );
let app_dst = core::slice::from_raw_parts_mut(
APP_BASE_ADDRESS as *mut u8,
app_src.len() );
app_dst.copy_from_slice(app_src);
}
注:fence.i
是i-cache屏障(barrier)指令,非特权指令,属于 “Zifencei”扩展规范
WHY?
fence.i :用来清理 i-cache
CPU 对物理内存所做的缓存又分成d-cache和i-cache
OS将修改会被 CPU 取指的内存区域,这会使得 i-cache 中含有与内存中不一致的内容
OS在这里必须使用 fence.i 指令手动清空 i-cache ,让里面所有的内容全部失效,才能够保证CPU访问内存数据和代码的正确性。
CSR 名 | 该 CSR 与 Trap 相关的功能 |
---|---|
sstatus | SPP 等字段给出 Trap 发生之前 CPU 的特权级(S/U)等 |
sepc | 记录 Trap 发生之前执行的最后一条指令的地址 |
scause | 描述 Trap 的原因 |
stval | 给出 Trap 附加信息 |
stvec | 控制 Trap 处理代码的入口地址 |
Why 使用两个不同的栈?
Why 使用两个不同的栈?
安全 安全 安全
const USER_STACK_SIZE: usize = 4096 * 2;
const KERNEL_STACK_SIZE: usize = 4096 * 2;
static KERNEL_STACK: KernelStack = KernelStack { data: [0; KERNEL_STACK_SIZE] };
static USER_STACK: UserStack = UserStack { data: [0; USER_STACK_SIZE] };
impl UserStack {
fn get_sp(&self) -> usize {
self.data.as_ptr() as usize + USER_STACK_SIZE
}
}
RegSP = USER_STACK.get_sp();
RegSP = KERNEL_STACK.get_sp();
#[repr(C)]
pub struct TrapContext {
pub x: [usize; 32],
pub sstatus: Sstatus,
pub sepc: usize,
}
pub fn init() {
extern "C" { fn __alltraps(); }
unsafe {
stvec::write(__alltraps as usize, TrapMode::Direct);
}
}
sret
指令让应用程序继续执行。sscratch CSR 重要的中转寄存器
在特权级切换的时候,我们需要将 Trap 上下文保存在内核栈上,因此需要一个寄存器暂存内核栈地址,并以它作为基地址指针来依次保存 Trap 上下文的内容。
但是所有的通用寄存器都不能够用作基地址指针,因为它们都需要被保存,如果覆盖掉它们,就会影响后续应用控制流的执行。
sscratch CSR 重要的中转寄存器
csrrw sp, sscratch, sp // 交换对 sp 和 sscratch 两个寄存器内容
保存通用寄存器的宏
# os/src/trap/trap.S
.macro SAVE_GP n
sd x\n, \n*8(sp)
.endm
Trap 处理的总体流程如下:
__alltraps:
csrrw sp, sscratch, sp
# now sp->kernel stack, sscratch->user stack
# allocate a TrapContext on kernel stack
addi sp, sp, -34*8
保存通用寄存器
# save general-purpose registers
sd x1, 1*8(sp)
# skip sp(x2), we will save it later
sd x3, 3*8(sp)
# skip tp(x4), application does not use it
# save x5~x31
.set n, 5
.rept 27
SAVE_GP %n
.set n, n+1
.endr
保存 sstatus 和 sepc
# we can use t0/t1/t2 freely, because they were saved on kernel stack
csrr t0, sstatus
csrr t1, sepc
sd t0, 32*8(sp)
sd t1, 33*8(sp)
保存 user SP
# read user stack from sscratch and save it on the kernel stack
csrr t2, sscratch
sd t2, 2*8(sp)
pub struct TrapContext {
pub x: [usize; 32],
pub sstatus: Sstatus,
pub sepc: usize,
}
# set input argument of trap_handler(cx: &mut TrapContext)
mv a0, sp
call trap_handler
让寄存器 a0 指向内核栈的栈指针也就是我们刚刚保存的 Trap 上下文的地址,这是由于我们接下来要调用 trap_handler 进行 Trap 处理,它的第一个参数 cx 由调用规范要从 a0 中获取。
sret
指令 //从内核态返回到用户态注:后面讲解“执行程序”时会比较详细的讲解"恢复Trap上下文"
#[no_mangle]
pub fn trap_handler(cx: &mut TrapContext) -> &mut TrapContext {
let scause = scause::read();
let stval = stval::read();
match scause.cause() {
Trap::Exception(Exception::UserEnvCall) => {
cx.sepc += 4;
cx.x[10] = syscall(cx.x[17], [cx.x[10], cx.x[11], cx.x[12]]) as usize;
}
...
}
cx
}
pub fn sys_exit(xstate: i32) -> ! {
println!("[kernel] Application exited with code {}", xstate);
run_next_app()
}
执行的时机
让应用程序执行
从内核态切换到用户态
Trap上下文
返回用户态让应用执行
sret
指令的硬件逻辑:
pc
<-- spec
CSR调用 run_next_app 函数切换到下一个应用程序:
__restore
函数,从刚构造的 Trap 上下文中,恢复应用程序执行的部分寄存器;sepc
CSR的内容为应用程序入口点 0x80400000
;scratch
和 sp
寄存器,设置 sp
指向应用程序用户栈;sret
从 S 特权级切换到 U 特权级。impl TrapContext {
pub fn set_sp(&mut self, sp: usize) { self.x[2] = sp; }
pub fn app_init_context(entry: usize, sp: usize) -> Self {
let mut sstatus = sstatus::read();
sstatus.set_spp(SPP::User);
let mut cx = Self {
x: [0; 32],
sstatus,
sepc: entry,
};
cx.set_sp(sp);
cx
ub fn run_next_app() -> ! {
...
unsafe {
app_manager.load_app(current_app);
}
...
unsafe {
__restore(KERNEL_STACK.push_context(
TrapContext::app_init_context(APP_BASE_ADDRESS, USER_STACK.get_sp())
) as *const _ as usize);
}
panic!("Unreachable in batch::run_current_app!");
}
__restore:
# case1: start running app by __restore
# case2: back to U after handling trap
mv sp, a0
# now sp->kernel stack(after allocated), sscratch->user stack
# restore sstatus/sepc
ld t0, 32*8(sp)
ld t1, 33*8(sp)
ld t2, 2*8(sp)
csrw sstatus, t0
csrw sepc, t1
csrw sscratch, t2
# restore general-purpuse registers except sp/tp
ld x1, 1*8(sp)
ld x3, 3*8(sp)
.set n, 5
.rept 27
LOAD_GP %n
.set n, n+1
.endr
# release TrapContext on kernel stack
addi sp, sp, 34*8
# now sp->kernel stack, sscratch->user stack
csrrw sp, sscratch, sp
sret
提问
sscratch 是何时被设置为内核栈顶的?
- 构造&加载 OS&APP - 基于RV特权级机制保护OS - 系统调用支持 - 特权级切换