“RISC-V”、“Trap”、“Exception”这三个词做底层开发的应该都不陌生。尤其是自己写过CPU或在NEMU这类模拟器上调过操作系统的人几乎每天都要跟它们打交道。我一开始也分不清Exception和Interrupt到底哪里不一样更搞不懂为什么一个非法指令就能让整个模拟器报出“bad trap”然后直接挂掉。后面自己动手做了RISC-V流水线CPU又在基于NEMU的系统里调试过好多次异常才算把这条链路真正摸透。这篇内容就是一次系统整理从概念拆解、硬件自动流程、异常委托到软件handler怎么写再到CPU设计时容易踩的坑一次说清楚。无论是刚入门RISC-V、在写裸机程序还是正在做CPU设计都值得认真读一遍。1. 先分清三个词Exception、Interrupt、Trap1.1 一类问题三个名字在RISC-V里这三个词经常被混着用但它们其实不是一个层次的东西。按照RISC-V手册的定义Exception异常是CPU执行指令时产生的同步事件比如非法指令、缺页、访问了不存在的地址。它跟当前指令直接相关同一个程序、同样的输入异常每次都会稳定复现。Interrupt中断是外部异步事件比如定时器到了、网卡有包到了。它跟当前正在执行的指令没有直接因果关系任何一条指令执行过程中都可能被中断打断。Trap陷阱不是一类独立的事件而是“异常或中断发生后CPU跳转到特定处理程序”的这个完整过程。换句话说trap是处理Exception和Interrupt的统一机制。这个划分很重要。很多文章把trap直接翻译成“陷阱”好像只有程序主动int 0x80才叫陷阱这其实误导了不少人。在RISC-V的语境里所有异常和中断发生后的控制权转移都叫trap。1.2 同步和异步关键是看“谁引起的”判断一个事件是Exception还是Interrupt最简单的方法是问一句它不是当前指令“搞”出来的。如果一条指令自己违法了比如执行了0xffffffff这种非法编码或者load地址越界了那就是Exception同步。如果CPU正老老实实执行指令结果时钟中断来了CPU被迫暂停手头工作去处理中断那就是Interrupt异步。在RISC-V的mcause寄存器里最高位第63位是Interrupt位。如果该位为1表示这是一个中断如果为0表示是一个异常。这个设计很直观拿到cause值先看最高位再查低位的异常码就行。1.3 为什么日常讨论中Trap比Exception更常用因为写代码的时候我们并不关心是异常还是中断只关心“现在控制权要跳到哪里去处理”。RISC-V统一用mtvec/stvec指向trap handler并没有为Exception和Interrupt设置两套完全独立的入口。于是在实现和调试的时候大家更习惯说“trap处理了”而不是区分“这是异常处理”还是“这是中断处理”。这也是为什么NEMU遇到无法处理的坏状态时会报“bad trap”而不是“bad exception”。不过在实际设计CPU时异常和中断的处理优先级、掩蔽方式、返回路径还是有差异的下面会逐步展开。2. 异常发生时硬件到底做了什么2.1 机器模式下最重要的几个CSRRISC-V有几个和控制流转移强相关的CSR理解它们才算真正理解trap。以机器模式为例mtvectrap入口地址。里面包含BASE入口地址和MODE0表示Direct模式全部跳到同一个地址1表示Vectored模式中断按编号跳到BASE4×cause。mcause记录trap原因。最高位是Interrupt低位是异常码。mepc记录发生trap的那条指令的PC。返回时mret会跳回这个地址。mtval记录附加信息。如果是地址类异常就是发生故障的虚拟地址如果是指令异常可能是非法指令的编码。mstatus状态寄存器里面的MPIE和MPP位负责保存中断使能和特权级信息。mscratch一个通用临时寄存器常用来做栈切换。这些CSR很多是机器模式特有的S-mode还有一套对应的stvec、scause、sepc、stval、sstatus。2.2 单步拆解一次trap的完整流程假设CPU当前运行在U-mode正在执行一条非法指令触发了一个Exception。RISC-V硬件会按固定顺序完成下面这些动作把当前特权级U-mode保存到mstatus.MPP字段。把mstatus.MIE当前中断使能保存到mstatus.MPIE。在trap期间关闭中断mstatus.MIE清零。更新mepc为当前异常指令的PC。更新mcause为异常原因比如非法指令对应值2。如果异常有附加信息更新mtval。把当前特权级切换到M-mode。跳转到mtvec.BASE指定的地址。这8步是硬件自动完成的不需要软件参与。RISC-V的设计哲学就是“硬件做最小必须操作剩下的交给软件”。注意上述顺序中关闭中断第3步非常关键。如果异常处理过程中又来了新的中断很可能会嵌套导致现场混乱。RISC-V选择在进入trap时自动关中断软件做好现场保护后再决定是否重新打开。2.3 中断和异常的返回路径mret与sret处理完trap后软件最后执行一条mret如果是从M-mode进入了handler或sret从S-mode进入。mret会执行这些动作PC恢复到mepc的值。特权级恢复到mstatus.MPP。把mstatus.MPIE的值恢复给MIE。将MPP设为最低支持特权级通常是U-mode。这里有个容易忽略的细节mret指令本身在RISC-V规范里是可写CSR的访存类指令在某些流水线实现中会被视为带副作用指令影响分支预测和指令淘汰。实际设计CPU时要注意mret的“终止指令”语义它类似于分支但恢复PC的来源不是分支目标而是mepc。2.4 异常优先级CPU设计必须搞清楚的顺序在流水线CPU里一条指令可能同时有取指异常、译码非法、访存异常。比如取指时发现页错误同时这条指令又是一个非法指令该怎么办RISC-V规范给出了异常优先级从高到低大致为指令地址访问错误指令地址页错误指令地址未对齐如果实现支持非法指令断点load地址未对齐load访问错误load页错误store/AMO地址未对齐store/AMO访问错误store/AMO页错误实际设计时还要区分同一指令的多个异常按此优先级选择同时还要考虑前后指令之间异常的回滚。比如第3条指令发生了异常但第1、2条指令已经提交了处理器需要能够正确恢复现场把mepc指向第3条指令并且保证第1、2条指令的效果不丢失。这不是简单的事我在自研CPU时就被“异常精确性”precise exception折磨过很久。3. 异常委托S-mode和操作系统怎么接住trap3.1 为什么需要异常委托如果每一个异常都跳转到M-mode处理操作系统运行在S-mode就无法直接处理系统调用、缺页等常见事件每次都要经过M-mode的固件转发代价太高。RISC-V因此引入异常委托机制可以把某些中断和异常直接路由到S-mode的stvec由S-mode自己处理。委托控制寄存器是mideleg和medeleg。mideleg的bit i为1表示第i号中断委托给S-modemedeleg同理是异常。实际是否支持某一位的委托取决于实现但大多数应用处理器都会把常见的异常和中断委托给S-mode。3.2 medeleg和mideleg怎么看比如Linux操作系统运行在S-mode它希望自己处理系统调用ecall from U-mode异常码8、缺页异常码12/13/15和外部中断中断码11取决于PLIC实现。那么在固件启动阶段会把medeleg的bit 8、12、13、15置1把mideleg的bit 11置1。委托之后U-mode执行ecall时硬件不再跳转到M-mode的mtvec而是直接跳转到S-mode的stvec。此时记录原因的是scause返回PC保存在sepc而不是mcause和mepc。有个细节委托并不意味着M-mode的mstatus.MIE变化而是特权级直接转换为S-mode并且进入S-mode的处理流程。如果S-mode处理不了仍然可以通过ecallM-mode的异常码11重新回到M-mode。3.3 系统调用ecall在委托后的完整路径以Linux/裸机程序为例用户程序执行ecall硬件发现ecall来自U-mode且scause被设置为8环境调用U-mode。特权级切换为S-modePC跳转到stvec。S-mode的异常入口保存现场解析scause。如果scause是8查syscall number执行系统调用。执行sret回到sepc指向的下一条指令ecall的下一条。如果没有委托这个流程会变成先到M-modeM-mode再转发给S-modeS-mode处理完还要mret回M-mode再mret回U-mode效率差很多。这也是为什么几乎所有现代RISC-V平台都会配置委托。4. 软件侧写一个能用的trap handler4.1 上下文保存别让handler毁掉现场硬件自动保存的信息只有mepc、mcause这些CSR通用寄存器是一个都没帮你存的。所以trap handler的第一件事就是保存现场。保存现场要考虑两个问题保存到哪保存哪些寄存器保存到哪通常有两种方案直接在异常之前的内核栈S-mode则可能用内核栈上保存。使用mscratch指向一个独立的trap栈通过交换sp来切换。保存哪些至少是所有调用者保存和临时寄存器x1、x2、x3、x5-x31以及可能的浮点寄存器。如果handler用到了某些寄存器而它又不打算再保存就必须全部保存。一个经典的汇编模板长这样trap_handler: # 用 mscratch 换栈 csrrw sp, mscratch, sp # 如果原来就在目标栈上则跳过保存 # 为保存上下文分配空间 addi sp, sp, -256 # 保存通用寄存器 sd x1, 0(sp) sd x2, 8(sp) sd x3, 16(sp) # ... sd x31, 248(sp) # 读 mcause判断异常类型 csrr a0, mcause # 转给 C 函数处理 call handle_trap_c # 恢复寄存器 ld x1, 0(sp) ld x2, 8(sp) # ... ld x31, 248(sp) addi sp, sp, 256 # 换栈换回去 csrrw sp, mscratch, sp mret注意这里的x2就是sp所以先分配好栈空间再保存x2或者在分配之前先把原始sp保存到临时寄存器。实际操作里很多人会在这里翻车因为换栈的时序没理清。4.2 用mscratch实现“换栈”的经典技巧为什么要“换栈”因为异常发生时原始栈可能是用户栈也可能是栈指针本身就是非法的比如栈被破坏、栈指针越界。如果trap handler继续用原来的sp可能连第一条保存指令的数据都写不进去现场就丢了。RISC-V提供的mscratch寄存器就是干这个的。常见做法开机初始化时把mscratch设置为一个可靠的trap栈顶地址。trap发生时执行csrrw sp, mscratch, sp。这条指令交换sp和mscratch。现在sp变成了trap栈顶mscratch保存了原来的sp。处理完后再次执行csrrw sp, mscratch, sp把原始sp换回来。这个技巧好就好在只需要一条指令而且不会覆盖任何通用寄存器。我第一次看别人这样写时觉得简单等自己调时才发现最怕的是trap嵌套第一次trap还没处理完又来了中断如果mscratch已经被交换过第二次进入时会又把sp换到某个未知地方。因此在设计长期运行的系统时中断嵌套必须小心处理通常要在handler开头就关中断或者用“双栈切换”方案。4.3 收尾mret之前必须检查的三个状态位很多新手写完handler恢复完寄存器直接mret结果程序跑飞。我在调试时总结出三个必须检查的地方mstatus.MPIE是否等于1如果进入trap前MIE是1允许中断硬件会把MPIE置1。你必须在mret前保证MPIE保持为1这样mret执行后MIE才能恢复为1。mepc是否正确如果handler在处理过程中修改了mepc比如要跳过某条指令或模拟某条指令一定要在mret前确认mepc已经是你想要的地址。MPP是否等于异常发生前的特权级如果MPP被错误设置为U-mode但实际异常发生在S-modemret就会错误地回到U-mode导致权限崩溃。在S-mode下对应的是sstatus.SPIE和spp。同理也需要检查。这里我给一个非常简单的C函数处理例子void handle_trap(void) { uint64_t cause csr_read(mcause); uint64_t epc csr_read(mepc); if ((cause 63) 1) { // 中断调用中断处理 handle_interrupt(cause 0xff); } else { switch (cause) { case 2: printf(Illegal instruction at 0x%lx, inst0x%lx\n, epc, csr_read(mtval)); csr_write(mepc, epc 4); // 跳过非法指令 break; case 8: // u-mode ecall, 处理系统调用 syscall_handler(); csr_write(mepc, epc 4); break; default: panic(Unknown exception, cause%lx, epc%lx\n, cause, epc); } } }注意这个例子里对mepc加4是假设非法指令或ecall都是32位指令。在RV64下如果压缩指令扩展RVC开启了非法指令长度可能是2字节不能简单加4。实际项目里一定要检查指令编码长度这是一个常见坑。5. 在NEMU和自研CPU中踩过的Trap坑5.1 “bad trap”到底是什么在NEMU南京大学PA项目中自研的模拟器里如果程序执行了无法处理的指令或状态NEMU会报“bad trap”并停机。这个“bad trap”并不是RISC-V规范里的正式术语而是模拟器里一个兜底处理当模拟器发现自己无法继续模拟下去比如遇见了未知指令、CSR访问异常或者程序主动触发了一个“神秘指令”用来结束运算时它就把当前trap状态当作“bad trap”打印出来。常见触发原因有CPU执行了0x00000000全零指令——没有实现或不支持。访问了未映射的物理内存地址。CSR读写时权限不足。程序跳转到了一个奇怪的地方取指失败。我调试NEMU时遇到“bad trap”后的第一步就是看它打印的nemu_trap寄存器或某个状态值以及对应的PC。PC很多情况下能直接指出问题如果PC指向了奇怪的地址多半是返回地址被破坏如果PC指向了一个数据段那可能是栈溢出写坏了返回地址。5.2 流水线CPU实现异常时容易漏的点如果你在写RISC-V流水线CPU这里有一个我踩过的大坑异常必须在指令“提交”commit时才正式生效不能在流水线前段就修改CSR。为什么因为流水线里有分支预测和乱序如果有前面的指令可能还在猜测执行。如果在EX阶段检测到异常就立刻写mepc但这条指令最后被取消了mepc就写错了。正确的做法是把异常信息跟着指令流水往下传在提交阶段通常是写回后或访存后才真正更新CSR并冲刷流水线。另一个容易漏的点是Ecall和非法指令的PC保存。异常指令的mepc应该保存那条指令自己的PCEcall允许在返回时跳到下一条指令但mepc本身还是指向Ecall那一条。很多人把mepc保存成下一条PC结果mret回来少执行了一条指令。还有异常优先级在硬件里同一拍要检查多个指令的异常。比如访存阶段发现load地址越界同时这一条load又是非法指令必须按规范优先级选。如果选错调试时就非常诡异——明明有更严重的非法指令硬件却报了load fault。5.3 调试异常问题的四个实用招我调试陷阱处理时会按下面顺序来检查mtvec是否设置正确。很多裸机程序跑飞就是因为没有初始化mtvec异常直接跳到了随机地址。在trap handler入口加一个打印。打印mcause、mepc、mtval以及发生异常时的sp。这三板斧能解决90%的问题。检查CSR的读写权限。在U-mode访问M-mode的CSR会触发非法指令异常在S-mode写mstatus的某些位也可能被忽略或触发异常。对比RISC-V规范里的异常码表。有时候你以为报的是“非法指令”其实是“指令访问错误”两者处理方式完全不同。下面是一张常用异常码表建议收藏异常码描述典型场景0指令地址未对齐跳转到非对齐地址1指令访问错误取指时物理地址不可读2非法指令指令解码失败3断点ebreak指令4load地址未对齐lw访问未对齐5load访问错误load到非法物理地址6store/AMO地址未对齐sw访问未对齐7store/AMO访问错误store到只读或非法地址8环境调用U-modeecall from U9环境调用S-modeecall from S11环境调用M-modeecall from M12指令页错误取指MMU缺页13load页错误load MMU缺页15store/AMO页错误store MMU缺页在S-mode下下表对应scause。操作系统缺页异常就是13/15Linux中do_page_fault会查看这些值。很多时候你看内核日志里报“Unable to handle kernel paging request at virtual address ...”背后就是这些异常码。最后一个实用技巧是在实现异常处理时可以在每个可能出错的地方设置一个“哨兵CSR”或者全局变量记录“上次经过的函数”。这样一旦发生bad trap不仅能打印PC还能顺着记录找出是哪个调用路径进入了异常。我在NEMU里加了一个简易的backtrace打印最近的函数调用点调试效率提升了一个档次。总的来说Trap和Exception看着是几个词深挖下去其实是CPU和操作系统协作最核心的机制。把异常优先级的硬件实现、CSR的原子更新、软件的上下文保存都串起来你就掌握了RISC-V中断异常体系的骨架。我最大的体会是不要只背概念一定要亲手写一次trap handler再在模拟器里故意制造一个非法指令亲眼看完处理前后的所有CSR变化这个知识点就彻底长在身上了。