pebstwck3/docs/2_OSLab/g3/catfish-proposal.md

# Rust OS多核移植与基于PARD框架的线程级Label管理 方案设计文档

2015011251 王纪霆

## 实验目标

+ 完成RustOS在riscv32上的多核开启
+ 使RustOS可在中科院计算所PARD RISCV硬件环境下运行
+ 使RustOS能够在PARD上开启smp
+ 添加控制功能，使得RustOS可以控制/查看PARD的寄存器

如果以上这些要全部实现，可以预料地将无法在八周内完成。

## 实验背景

[LvNA/PARD](https://github.com/LvNA-system/labeled-RISC-V)是一个用于进行内存隔离的硬件系统。它基于[rocket-chip](https://github.com/freechipsproject/rocket-chip)实现，在通常的多核以外，在核与各存储设备间增加了寄存器和额外的模块，并且对总线访问添加了标签，两者相结合下，可以完成对总线访问的控制，即对各核能够使用的缓存大小、磁盘流量进行限制等。

但目前为止，这项工作还有一些问题。首先是作为控制流量的关键——control plane，并未暴露给各核，而需要通过硬件的JTAG机制与板子上的控制模块prm（内含一个linux系统）沟通，并且在prm上实现控制脚本。而prm又和各核无法直接沟通，这样，运行在各核上的OS不仅无法修改寄存器，也无法知晓自己所分配到的资源大小，与PARD系统完全隔离。

如此一来，这个系统仅能进行核间的隔离，而无法完成进程间的隔离。这是因为，为了区分进程、给两个进程打上不同的标签，就必须让OS可以主动修改和设置control plane。

解决这个问题，实现进程级的label管理就是这个项目的主要目的。

## 实验设计

实际上，本项目的两个方向，即多核移植和PARD移植，是可以独立完成的。因为也可以退而求其次，考虑在PARD上只运行单核的线程级标签管理。但最终的目的还是让RustOS接手PARD的所有核，作为一个多核OS运行，对整个系统的运行进行管理。

最理想的方法是让硬件把control plane映射到内存，作为各核的一个设备。但硬件非常复杂，并且中科院方也没有实现这一功能。所以还是对硬件不做修改，依旧通过prm管理control plane，而将prm用串口等和各核连接，让其作为核的一个设备，在核的控制下修改底层配置。

为此，需要做的具体来说是：

+ 让RustOS可以在核上运行；
+ 在prm上写脚本（运行在完善的Linux环境，且有现成范例），控制control plane；
+ 在RustOS上写驱动，使其可以与prm交互完成控制；
+ 在RustOS中添加系统调用等，使得操作系统可以管理驱动；

另一边，多核移植所要做的是：

+ 开启多核，实现原子操作等，为内核中可能的竞争加锁（Rust已经帮我们做了很多）；
+ 核间进程调度，load balance；

多核这边打算做的简单一些，基本照搬uCore+ on rv64来做，因为主要的设计和优化工作应该交给wrj同学。

## 目前进度

PARD端：

+ 完成了实现机理的调研
+ 正在服务器上编译复现（工程太大，本地vivado编译不了）

多核端：

+ 完成了ucore+ smp的初步学习
+ 学习了bbl，完成了RustOS on rv32的多核开启

## 暂时计划

如果必须前八周结束，估计是无法做完的。

根据能否在前八周过后继续做，有以下远近期的计划：

### 短期

+ 完成rv32 on smp的移植（第5-6周）
+ 完成多核Rust OS在PARD上的运行（第7-8周）

### 长期

+ 完成RustOS与PARD的交互协议构建（第9-11周）
+ 实现基于RustOS的进程级标签管理（第12周后）

以上均基于只有本人一人工作的前提，若有其他人协助/加入则根据实际情况而定。