kayoch1n
kayoch1n
@sorrycc 打搅一下，有时间review一下不？
> 以及还想问一下在给`HEAP_ALLOCATOR`初始化的时候用到的`HEAP_SPACE`的大小是`0x2000000`，可是我们的物理内存实际大小不是也是只有8MB吗？ QEMU 给到的内存大小也不止8MB，0x80000000..0x88000000 有128MB，是默认值，可以通过参数 -m 调整比如 -m 256M > [rustsbi] Implementation : RustSBI-QEMU Version 0.2.0-alpha.2 > [rustsbi] Platform Name : riscv-virtio,qemu > [rustsbi] Platform SMP : 1 > [rustsbi]...
[2.4 第三点的描述](https://rcore-os.cn/rCore-Tutorial-Book-v3/chapter3/6answer.html#id9)感觉不对 > 通过时钟中断切换任务： > ... > 切换到新任务后，在 trap 结尾处遇到函数 user_time_start()，刷新停表，并统计新任务的内核态时间 按照 [ch3 的实现](https://github.com/rcore-os/rCore-Tutorial-v3/blob/ch3/os/src/task/mod.rs#L133)，__switch 函数通过直接恢复ra来切到新任务，不会返回到trap的结尾
> @kayoch1n 没问题呀，假设是两个任务轮流执行的情况，一个任务时间片用尽进入trap，调用`suspend_current_and_run_next`，最终调用`__switch`切换到另一个任务。另一个任务时间片也用尽，通过`__switch`切换回来的时候，要切换回的ra其实是调用`__switch`的指令的下一条指令，所以会从`__switch`返回的地方继续执行，最后走到trap结尾。再看看`__switch`对ra的处理吧。 ok了，我的代码有点问题，修改之后是可以返回并且走到trap结尾的
关于[第三个问题支持浮点运算](https://rcore-os.cn/rCore-Tutorial-Book-v3/chapter3/6answer.html#a)，我觉得可以提一下需要事先将 sstatus.fs 设置为一个非0的值，否则尽管编译target包含了浮点指令拓展、程序首次执行浮点指令的时候会抛出illegal instruction异常。 [这里3.1.6.6](https://five-embeddev.com/riscv-isa-manual/latest/machine.html#machine-status-registers-mstatus-and-mstatush)有提到这个点，而且我自己在qemu上试了一下确实会直接抛出异常，设置成1之后可解决这个首次执行异常的问题 > When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction...
> 请问为什么`trap.S`中的`__alltraps`中的上下文不直接保存在应用对应的内核栈中而是保存在TrapContext对应的内存中 我猜是因为 __alltraps 刚进入的时候还是在应用空间。应用的内核栈是要在内核空间才能访问的，所以得先从 trap context 装载对应的 satp，而 trap context 在应用空间。这应该也是内核栈 跟 trap context分别在不同的 page的原因。
我的代码反复输出同一条内容，看起来是rust_main -> panic! -> shutdown -> panic! -> shutdown 陷入递归了，我猜原因是在我这儿用于 ecall shutdown 的值可能不是 8，所以 sbi_call(8) 的时候没有真正关机。但我确实是用的 qemu-system-riscv64，而且 rustsbi-qemu 也是拉取最新代码编译的。求助是否有思路定位原因？ ``` Hello, world! panicked at src/main.rs:17 Shutdown machine! panicked at src/sbi.rs:27...
> @kayoch1n 如果你使用了最新的rustsbi的话，请注意SBI标准已经发生了更改。将源代码改为如下形式可以完成功能。 > > ```rust > //src/sbi.rs > > use core::arch::asm; > #[allow(unused)] > > // legacy extensions: ignore fid > const SBI_SET_TIMER: usize = 0; > const SBI_CONSOLE_PUTCHAR:...
> 首先是从 ELF 文件生成一个全新的地址空间并直接替换进来（第 15 行），这将导致原有的地址空间生命周期结束，里面包含的全部物理页帧都会被回收； exec里面会回收掉老的memoryset结构，但其实只是放到一个全局结构里存着，并不会抹除物理页上的内容，而且satp也没改，还是老的memoryset的token，这个地方是设计如此吗？ 如果控制流在回到应用程序之前，发生了分配物理页而且刚好是satp对应的那个物理页，然后被写入内容覆盖了，是不是就会出问题了？
> 实现这一章的代码时遇到了一个奇怪的 bug: 每当第一个程序退出时, 内核总是会陷入死循环, 无法继续运行. 经过调试后, 发现原因是我把 `MAX_APP_NUM` 设置成了 `512`, 改成 `4` 后即可正常运行. 试了一下把 `MAX_APP_NUM` 调到 330 左右就会触发这个 bug: > > ```rust > // os/src/config.rs > > pub const...