• sbi 实现

  • 根据标准重新审查函数实现，依赖新版 rustsbi
  • 移除堆分配
  • 重写上下文切换
  • 使用新的设备树解析方案，尽量从设备树解析各模块地址和长度
  • 配置更精细的 pmp
  • 模块
    • srst
      • [x] shutdown
      • [ ] reboot
    • hsm
      • [x] hart_start
      • [x] hart_stop
      • [x] hart_get_status
      • [x] hart_suspend

• 测试内核

  • 分离 sbi-rt 子项目，特权软件可基于此项目调用 sbi ecall（不限于 rustsbi）
  • 测试项目
    • [x] 引导特权软件
    • [x] base
    • [ ] legacy (deperacated)
    • [x] time csr
    • [x] exception delegate
    • [x] hsm
    • [x] srst

• 测试通过情况

  • [x] 测试内核单核
  • [x] 测试内核多核
  • [x] rCore-Tutorial-v3
  • [x] zCore 单核
  • [x] zCore 多核

您好！ 我正在尝试跑通rcore。 按照 http://rcore-os.cn/rCore-Tutorial-Book-v3/chapter0/5setup-devel-env.html 里的描述，可以正常在WSL和物理机上跑通rcore。 然而，我注意到有一个rcore的实验指导，专门为了做实验的同学设计的，这里面的代码和tutorial稍有不同，我尝试跑通实验指导三：虚拟内存的时候的时候，出现了以下奇怪的情况:

物理机+opensbi(qemu参数改为default): 正常运行！ 物理机+rustsbi2.2.0： 运行失败！ 具体来说，在虚拟内存开启之后(mm::init()之后)，println宏无法打印变量的值，此时PC不知道跑哪去了，再也没有输出了！ WSL+opensbi： 所有章节的rcore都运行失败！（rcore指的是实验指导的rcore，不是tutorial的rcore） WSL+rustsbi: 没有虚拟内存的章节的rcore可以正常运行，但是开启了虚拟内存章节的rcore运行失败！

It looks good in windows :

PS C:\Rust\rustsbi-qemu> cargo qemu
    Finished release [optimized] target(s) in 0.06s
     Running `target\release\xtask.exe qemu`
    Finished release [optimized] target(s) in 0.06s
    Finished release [optimized] target(s) in 0.06s
[rustsbi] RustSBI version 0.3.0-alpha.4, adapting to RISC-V SBI v1.0.0
.______       __    __      _______.___________.  _______..______   __
|   _  \     |  |  |  |    /       |           | /       ||   _  \ |  |
|  |_)  |    |  |  |  |   |   (----`---|  |----`|   (----`|  |_)  ||  |
|      /     |  |  |  |    \   \       |  |      \   \    |   _  < |  |
|  |\  \----.|  `--'  |.----)   |      |  |  .----)   |   |  |_)  ||  |
| _| `._____| \______/ |_______/       |__|  |_______/    |______/ |__|
[rustsbi] Implementation     : RustSBI-QEMU Version 0.2.0-alpha.2
[rustsbi] Platform Name      : riscv-virtio,qemu
[rustsbi] Platform SMP       : 8
[rustsbi] Platform Memory    : 0x80000000..0x88000000
[rustsbi] Boot HART          : 6
[rustsbi] Device Tree Region : 0x87e00000..0x87e01925
[rustsbi] Firmware Address   : 0x80000000
[rustsbi] Supervisor Address : 0x80200000
[rustsbi] pmp01: 0x00000000..0x80000000 (-wr)
[rustsbi] pmp02: 0x80000000..0x80200000 (---)
[rustsbi] pmp03: 0x80200000..0x88000000 (xwr)
[rustsbi] pmp04: 0x88000000..0x00000000 (-wr)
.....................

But when I try to run it in ubuntu22.04, an error was thrown out in the beginnig like this:

$:~/workspace/debug/rustsbi-qemu$ cargo qemu
    Finished release [optimized] target(s) in 0.01s
     Running `target/release/xtask qemu`
    Finished release [optimized] target(s) in 0.01s
    Finished release [optimized] target(s) in 0.01s
xtask: QEMU command not found. Does your system have QEMU installed and environment variable configured?
xtask: error: No such file or directory (os error 2)
$: ~

The Rustsbi binary was downloaded from https://github.com/rustsbi/rustsbi-qemu/releases/download/v0.1.1/rustsbi-qemu-release.zip.

$ qemu-system-riscv64 --version
QEMU emulator version 6.2.0
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
$ qemu-system-riscv64 -machine virt -nographic -bios ../bootloader/rustsbi-qemu.bin -smp 1
[rustsbi] RustSBI version 0.2.2, adapting to RISC-V SBI v1.0.0
[logo]
[rustsbi] Implementation: RustSBI-QEMU Version 0.1.1
[rustsbi-dtb] Hart count: cluster0 with 1 cores
[rustsbi] misa: RV64ACDFIMSU
[rustsbi] mideleg: ssoft, stimer, sext (0x222)
[rustsbi] medeleg: ima, ia, bkpt, la, sa, uecall, ipage, lpage, spage (0xb1ab)
[rustsbi] pmp0: 0x10000000 ..= 0x10001fff (rw-)
[rustsbi] pmp6: 0x2000000 ..= 0x200ffff (rw-)
[rustsbi] pmp12: 0xc000000 ..= 0xc3fffff (rw-)
[rustsbi] enter supervisor 0x80200000
$ qemu-system-riscv64 -machine virt -nographic -bios ../bootloader/rustsbi-qemu.bin -smp 8
[rustsbi] RustSBI version 0.2.2, adapting to RISC-V SBI v1.0.0
[logo]
[rustsbi] Implementation: RustSBI-QEMU Version 0.1.1
[rustsbi-dtb] Hart count: cluster0 with 8 cores
[rustsbi] misa: RV64ACDFIMSU
[rustsbi] mideleg: ssoft, stimer, sext (0x222)
[rustsbi] medeleg: ima, ia, bkpt, la, sa, uecall, ipage, lpage, spage (0xb1ab)
[rustsbi] pmp0: 0x10000000 ..= 0x10001fff (rw-)
[rustsbi] pmp6: 0x2000000 ..= 0x200ffff (rw-)
[rustsbi] pmp12: 0xc000000 ..= 0xc3fffff (rw-)
[rustsbi] enter supervisor 0x80200000

The PMP output was not correct. Actually, the expected output is:

[rustsbi] pmp0: 0x10000000 ..= 0x10001fff (rw-)
[rustsbi] pmp1: 0x2000000 ..= 0x200ffff (rw-)
[rustsbi] pmp2: 0xc000000 ..= 0xc3fffff (rw-)
[rustsbi] pmp3: 0x80000000 ..= 0x8fffffff (rwx)

It was very weird that when I tested using cargo qemu under the rustsbi-qemu root directory, the output was correct. I did not know what happened.

Another question is that rCore-Tutorial-v3 cannot work normally using rustsbi-qemu version 0.1.1 if the tutorial is built in debug mode. However, it works under release mode. Therefore, I decide not to upgrade rustsbi for a while...

Rustsbi version: at commit 269d1d32b4c0fd4900e6db1f070e7a2ce983dd14 QEMU version: 5.2.0

Minimalist test case:

int main() {
  w_stvec((uint64_t)kvec_asm); // i put some printf in interrupt handler
  s_sstatus(SSTATUS_SIE);
  s_sie(SIE_SSIE | SIE_STIE | SIE_SEIE);
  sbi_legacy_set_timer(r_time() + 30000000);
  // struct sbiret r = sbi_set_timer(r_time() + 30000000);
  // printf("%l, %l\n", r.error, r.value);
  while(1);
  return 0;
 }

When i use the legacy sbi_legacy_set_timer(), the code works as expected, outputs a lot.

When i use the new sbi_set_time(), it seems that timer interrupt was never triggered..

I have traced the code, the params were properly passed.

Is the difference an expected behavior?

Thanks ~~~

Now rustsbi-qemu doesn't allow S mode software use devices provided by qemu because we havn't set pmp registers for them.

Noticed that qemu provides more than one board, and they have different MMIO. We need to discuss how to set pmp registers properly.

现在 rustsbi-qemu 不允许 S 态软件使用 qemu 提供的设备，因为我们没有为它们设置 pmp 寄存器。

注意到 qemu 提供了不止一种板子，而且它们有不同的 MMIO。我们需要讨论如何正确设置 pmp 寄存器。

If anyone who wonder how to use devices in qemu, here is an example of using uart0 (uart0_mmio base 0x10000000 lenth 0x100) in virt machine:

如果任何人想知道如何使用 qemu 的外设，下面是使用 virt 的 uart0 (uart0_mmio 基址 0x10000000 长度 0x100) 的一个例子：

fn set_pmp() {
    unsafe {
        asm!(
-            "li     {tmp}, ((0x08 << 16) | (0x1F << 8) | (0x1F << 0))", // 0 = NAPOT,ARWX; 1 = NAPOT,ARWX; 2 = TOR,A;
+            "li     {tmp}, ((0x08 << 24) | (0x1F << 16) | (0x1F << 8) | (0x1F << 0))", // 0 = NAPOT,ARWX; 1 = NAPOT,ARWX; 2 = TOR,A;
            "csrw   0x3A0, {tmp}",
            "li     {tmp}, ((0x0000000080000000 >> 2) | 0x3ffff)", // 0 = 0x0000000080000000-0x000000008001ffff
            "csrw   0x3B0, {tmp}",
            "li     {tmp}, ((0x0000000080200000 >> 2) | 0x1fffff)", // 1 = 0x0000000080200000-0x000000008021ffff
            "csrw   0x3B1, {tmp}",
+            "li     {tmp}, ((0x0000000010000000 >> 2) | 0x3f)",
+            "csrw   0x3B2, {tmp}",
            "sfence.vma",
            tmp = out(reg) _
        )
    };
}

• fix: 改正中断转发的实现，现在 ssoft 和 stimer 都正常响应
• refactor: 用 sbi-testing 测试
• refactor: 实现一些访问 clint 的裸函数，现在 m 态代理 s 中断不需要切换上下文

Signed-off-by: YdrMaster [email protected]

在现有的处理中： https://github.com/rustsbi/rustsbi-qemu/blob/96704cf4373b9eb804145268862ba92700e46b27/rustsbi-qemu/src/feature/transfer_trap.rs#L23 仅仅设置SPP为S态似乎有些草率。比如在xv6中，若是在用户态触发了非法指令异常，那么在异常处理函数中会判断该异常是否来自于用户态：

if((r_sstatus() & SSTATUS_SPP) != 0){
  panic("usertrap: not from user mode");
}

若按上述设置，那么将会触发panic，这对于debug来说颇具误导性...

比较合适的设置方法应该是根据现有的MPP来设置SPP：

// 设置中断位
if ctx.mstatus.mpp() == MPP::User {
    mstatus::set_spp(SPP::User);
} else {
    mstatus::set_spp(SPP::Supervisor);
}
    
mstatus::set_mpp(MPP::Supervisor);

我这边观察到的rustsbi的行为是，每一个hart都会启动进入系统内核，并且hartid不为0的hart才能接受到a1 （device tree）参数。相同的代码用qemu自带的sbi跑，只有hartid为0的hart启动进入内核，能接受到device tree，其他hart为Stopped状态。 是否应该期望两者行为一致，还是说这是一种feature？

我在使用cargo qemu进行编译，显示了如下错误。 因此，我认为是rustsbi v0.2.0-alpha.8导致的编译错误。 这是我使用的toolchain 的情况： 奇怪的是，我在rustsbi的仓库下（https://github.com/rustsbi/rustsbi/） 对rustsbi的最新版本0.2.0-alpha.9进行编译不会报错。 并且编译rustsbi使用的toolchain和编译rustsbi-qemu时使用的toolchain相同：

看上去问题 的根源应该是最新版本的toolchain不太适配rustsbi v0.2.0-alpha.8导致的编译错误。

Now we support PLIC/CLINT/VIRTIO0/UART/DRAM. We also add a handy function which helps you calculate pmpaddr and write some comments about how PMP works.

I'm currently using qemu 7.0.0 for risc-v system emulation. However, the current version of device tree compiler might caught problem. If we use git clone to get the qemu source and compile it, the qemu does not work properly as it gets stuck in a loop before jumping to the kernel. The execution trace of this loop shows below. It causes RustABI in an infinite loop around address 0x80001b00:

(gdb) si
0x0000000080001b00 in ?? ()
(gdb) si
0x0000000080001b04 in ?? ()
(gdb) si
0x0000000080001b08 in ?? ()
(gdb) si
0x0000000080001b0c in ?? ()
(gdb) si
0x0000000080001b10 in ?? ()
(gdb) si
0x0000000080004394 in ?? ()
(gdb) si
0x0000000080001b14 in ?? ()
(gdb) si
0x0000000080001b18 in ?? ()
(gdb) si
0x0000000080001b00 in ?? ()
(gdb) x/10i $pc
=> 0x80001b00:	fence	w,unknown
   0x80001b04:	lb	a0,8(s1)
   0x80001b08:	fence	r,rw
   0x80001b0c:	auipc	ra,0x3
   0x80001b10:	jalr	-1912(ra)
   0x80001b14:	zext.b	a0,a0
   0x80001b18:	blez	a0,0x80001b00
   0x80001b1c:	bne	a0,s0,0x80001b26
   0x80001b20:	fence	w,unknown
   0x80001b24:	j	0x80001b04
(gdb)

I infer this problem is caused by dtc submodule is because if we download source code tar file of qemu 7.0.0 on official website, which include all of the component at that time including the full copy of old version dtc, qemu will work as expected. The only difference between the git clone version and .tar file of qemu 7.0.0 is the submodules (including dtc and a building system). I have tried many kinds of platform and it yields the same result.

Is possible that the test suite can support binary input, and go through the know cases under qemu? e.g. The sbi binary like 'fw_jump.bin' and 'fw_jump.elf' can be generated in opensbi/build/platform/generic/firmware/.. https://github.com/riscv-software-src/opensbi.git

目前rustsbi-qemu在收到M态软件中断时，只会判断上一个HSM命令，如果不存在就直接 panic ，导致S态软件无论是通过SBI s-IPI扩展还是直接访问Clint都无法使用IPI功能（除非是ACLINT）。

一个最直接的hack就是发现没有HSM命令时，把软件中断直接转发给S态；不过这样可能处理不了rfence扩展，应该得再加一套或者两套命令接口。