关于trap过程中的context的保存与恢复相关讨论

[Ayana-chan]

问题的产生

trap这个过程其实很像函数调用。我们知道函数调用时各个寄存器分为调用者保存和非调用者保存。但看trap（从P1态转移到P2态）时的context，保存的所有普通寄存器都可以看成是被调用者保存，是P2在保存P1的状态；但是，context中又保存了sstatus和sepc，这个既不是上级调用者的东西（因为这个是trap后才产生的，而且在trap结束的一瞬间就失去意义），也不是成为调用者时自发保存的东西（因为即使不发生进一步的嵌套trap，这些寄存器依旧被保存了）。

这就使得context的保存内容“没有特别稳定的理论依据”。

进一步思考

换句话说我们完全可以这么做：context只保存普通寄存器，当嵌套trap发生时，由trap的被调用方主动保存调用方的特殊寄存器。换句话说，普通寄存器和特殊寄存器都使用被调用者保存。

经过整理，发现实际上是这样的模型：

• 如果是U态trap到S态，则只需要保存普通寄存器；
• 如果是S态trap到S态，则要保存普通寄存器的同时也要保存特殊寄存器，因为此时特殊寄存器也是程序上下文的理所应当的组成部分。

似乎xv6就是这么做的。

唯一带来的副作用似乎只是让上下文保存的时候多了几个条件分支。如果按rcore现在的实现进行无脑进行存储的话，可以大大降低复杂度（nju ics pa里面也是几乎一样的无脑存储）。

新的论点

假如 P1 是因为时钟中断进入 S，要让给 P2，如果不保存 sepc 的话，P2 就回不去了。

trap调用trap代码，自然可以自洽，但如果trap的时候发生其他异常，就有可能破坏状态。但这部分我的总结尚不深刻，因此希望评论区有dalao能给出一个较为系统的、具体的论证。

[Ayana-chan]

补充，地址空间章节提到S->S的trap是被特殊处理的，因此此问题仅考虑U->S的trap