做嵌入式或者做CPU验证的同行多少都有过这种经历拿到一款RISC-V芯片的手册翻到中断章节结果发现一个很有意思的事实——你在RISC-V核内部找不到像Cortex-M那套NVIC一样的整组优先级寄存器。中断优先级的仲裁活大部分被放在了核外部的中断控制器里。PLIC和APLIC哪怕你没亲手配过也应该听过前者是RISC-V早期普及最广的平台级中断控制器后者是AIA规范里推出的继任者。这篇文章我会从实际配置和调试视角把两者的中断优先级机制从头拆到尾告诉你外设中断是怎么分级、仲裁、最终触发CPU的也把我在真实项目里踩过的一些优先级坑一并交代清楚。1. 想在CPU里找中断优先级RISC-V的答案其实是“在门外”1.1 核只负责“跳不跳”优先级裁决交给了外部控制器很多从ARM生态转过来的人一开始都会在RISC-V核的手册里翻找类似“NVIC_IPR”的寄存器。找了一圈之后往往会问全局中断使能我看到了mstatus.MIE、mie.MEIE这些我也看到了那优先级呢优先级在哪配答案是在绝大多数RISC-V实现里核本身不感知外设中断的优先级。核只知道自己收到了一个外部中断请求然后根据mstatus.MIE、mie.MEIE以及当前的特权模式决定要不要跳去mtvec/ stvec指向的入口。至于这个中断是来自UART还是DMA是紧急的看门狗还是无关紧要的触摸屏核一概不判断。判断这个的是“门外”的中断控制器。传统上叫PLIC也就是Platform-Level Interrupt Controller。你可以把它理解成一个位于SoC内部、CPU核之外的硬件服务员。所有外设中断先汇到它这里它根据每个中断源的优先级、使能位、以及目标CPU核设定的阈值挑出一个“当前最该被处理”的中断再向CPU核发一个中断请求信号。这里就有第一个容易误解的点RISC-V的优先级不是“所有中断统一排序”而是先分了两大类。核内部的中断——比如软件中断、定时器中断由核内本地中断控制器处理优先级相对固定核外部的设备中断——UART、SPI、DMA、GPIO这些——才走PLIC或者APLIC通过我们配的优先级寄存器来排序。这两大类之间的相对优先级又要靠核的全局中断使能和异常委托机制去协调。你如果在一个项目里发现“定时器总是抢在外部中断前面”不一定是你PLIC配错了很可能是核内中断与核外中断的交互关系没理清。1.2 理清PLIC/APLIC在系统里的角色把中断链路拆开看一个完整路径大概是这样外设产生中断条件后拉高自己的中断请求线也就是IRQ线。IRQ线连接到中断控制器的输入端。中断控制器PLIC或APLIC汇总多个IRQ做优先级仲裁选择一个中断后向CPU核的中断引脚发出请求。CPU核收到外部中断请求后如果全局中断使能并且对应的核级中断使能位比如mie.MEIE打开就跳转到异常入口把当前流程打断进入中断服务程序。这个链路里面中断控制器里的“仲裁”就是优先级机制的核心。PLIC的仲裁比较简单粗暴每个中断源有一个优先级CPU核有一个阈值。只有中断源优先级大于阈值的中断才被考虑然后从这些候选中选优先级最高的。如果有多个同样优先级那就按中断源编号从小到大的顺序“平局决胜”。而APLIC作为PLIC的后继者并不是简单地把这套思路升级了一下而是换了一套更灵活的分发模型。它引入了“域”和“IDC”的概念支持直送模式和MSI模式优先级语义也发生了改变。很多人看规范看得头疼就是没从“PLIC那套老模型”里跳出来。后面我会专门用一节讲清楚APLIC的域和优先级行为。2. 从外设触发到CPU跳转完整走一遍PLIC中断链路2.1 一个外设拉了IRQ之后硬件到底做了什么别急着写代码先把硬件行为在脑子里过一遍。比如你有一个UART收到一帧数据后拉高了UART的IRQ。这根线接到PLIC的某个中断源输入假设是source 10。硬件那边同步发生的事情是PLIC检测到source 10的电平为有效通常是高电平具体看芯片实现。PLIC将该source对应的pending位置1表示“这个中断已经发生了还没被处理”。PLIC读source 10的priority寄存器得到一个数值比如4。PLIC读目标CPU的threshold寄存器假设CPU0的threshold是0。因为4 0并且source 10的enable位为1所以source 10成为候选。如果此时没有更高优先级的source也在pendingPLIC就向CPU0发出中断请求信号。这个阶段CPU其实还不知道发生了什么只是自己的外部中断引脚被拉高了。等CPU完成当前指令、确认可以响应中断后硬件会跳转到mtvec如果跑在M模式或者stvec如果委托给了S模式同时把mepc保存成被中断指令的地址把mcause的中断原因编码设置成外部中断的编号。你注意看这一整条链路里PLIC并没有直接告诉CPU“你该处理的是source 10”。CPU进入中断服务程序之后必须自己去PLIC的门铃寄存器也就是claim/complete寄存器读一次才能知道具体是哪个中断源需要处理。这就是PLIC架构里非常核心的一个设计中断请求与中断识别是分离的。2.2 高优先级和低优先级同时到达谁被送到核上假设两个外设同时拉高IRQsource 5优先级是7source 10优先级是3两个都pending都enable阈值是0。PLIC的仲裁结果一定是选source 5因为7比3大。CPU在响应后进入中断入口软件读claim寄存器得到的中断号是5那么服务程序就先去处理source 5。这里有个容易被低估的细节如果source 5处理完了软件往complete寄存器写回5PLIC此时才会重新评估“还有没有其他pending且优先级达标的中断”。如果source 10还在pendingPLIC会再次向CPU发出中断请求。这第二次请求会等到当前中断服务程序退出、并且CPU重新开启中断使能之后才会被真正响应。所以PLIC的“优先级”在第一层含义上是决定“下一次该把哪个中断送给CPU”而不是像Cortex-M那样可以在中断服务程序执行到一半时用另一个更高优先级的中断把当前ISR打断。当然软件可以自己实现打断。但那是软件层面的抢占不是PLIC硬件直接支持的行为。后面我会专门提。2.3 为什么“优先级”和“抢占”在RISC-V里被拆开了ARM的NVIC把优先级和抢占绑得比较死一个中断如果优先级更高硬件可以直接抢占正在执行的低优先级ISR还支持尾链技术让连续中断处理更高效。RISC-V的PLIC把这两件事拆开了硬件层面只负责“排序和挑选”不负责“打断正在执行的ISR”。为什么这样设计一方面是RISC-V规范想保持核的简洁把中断控制器做成可由各SoC厂商灵活扩展的组件另一方面PLIC抢占并不是做不到而是被放到了系统软件层面去决定。你完全可以在ISR里打开全局中断并允许更高优先级中断去抢占当前处理过程——很多RTOS就是这么做的。实现方式就是在进入中断服务程序后不等退出就重新写mstatus.MIE1然后在退出时小心恢复上下文。这个设计带来的实际影响是你在RISC-V上调中断优先级时必须清楚知道“硬件优先级”和“软件抢占策略”是两条线。硬件优先级只控制PLIC选择哪个中断上报软件抢占策略控制ISR里是否允许嵌套。很多中断“不响应”或“响应顺序不对”的诡异问题就出在这两个概念的混淆上。3. PLIC的仲裁内核priority、threshold和claim/complete3.1 priority和threshold的仲裁规则PLIC里的优先级字段RISC-V官方spec给了建议但不强制通常是0到15占4位。0是特殊值表示“该中断永远不会被上报”。1到15表示从最低到最高的15个有效优先级。也有的实现会支持多达4096个中断源priority寄存器位宽做得更大但大部分看到的是4位这个要按具体芯片手册为准。仲裁时PLIC执行的是一个非常朴素的规则集合只考虑enable为1且pending为1的中断源。去掉priority小于等于threshold的中断源。剩下中断源中priority值最大的胜出。如果最大值有多个中断源编号最小者胜出。这里有一个很多人会忽略的地方threshold的语义是“严格大于”还是“大于等于”。RISC-V PLIC规范说的是“interrupt is not forwarded if the value of its priority is less than or equal to the threshold”也就是说条件是 priority threshold 才会转发。如果你的threshold写的是7那priority等于7的中断不会被转发这跟很多人的直觉相反。实际项目里我见过不止一次把阈值设置成了7然后priority也配7结果中断一直不触发查半天还以为是GPIO配置错了。3.2 claim/complete 为什么是PLIC的命根子说一下实际工作里的体验第一次对着PLIC写驱动最不习惯的就是那个claim/complete寄存器。你甚至会觉得它很绕为什么不直接在中断状态寄存器里读位图为什么要设计一个“读即得、写即清”的特殊寄存器设计原因其实很现实。中断控制器要避免一个经典竞态中断发生后软件正在读pending寄存器的时候同一中断又再次发生。如果软件靠读位图来判断读到的可能是一个过时状态还可能漏掉新来的中断。claim/complete机制把“识别中断”和“清除pending”绑定在一起软件从claim寄存器读一次硬件同时执行两个动作——告诉软件当前最高优先级的中断源编号并把该中断源的pending位清掉。等到中断处理完成软件要往complete寄存器写回同一个中断源编号。硬件收到这个写操作才会真正把该中断源标记为“处理完毕”允许下一次同源中断再次上报。如果在处理过程中该中断又来了新的pending会被置上但不会马上上报——因为上一次还没complete。这个语义在实际调试时特别容易踩坑。比如你的ISR因为某个原因没有写complete就返回了后果就是这个中断再也不会被响应看起来像“中断死锁”。所以如果你的RISC-V板子出现“某个中断跑一次之后永远不来了”我第一个要查的往往就是complete有没有写、写的是不是同一个中断号。3.3 实践中的差异QEMU与真实芯片我最早调PLIC是在QEMU上。QEMU的PLIC实现相对简化很多情况下它的时序是理想的不存在真实芯片里的绕线延迟、同步级数、电压域转换等物理因素。结果一到真实芯片上行为出现了几个明显差异中断源编号可能不连续芯片厂商会预留空洞。你按文档写一个连续for循环去初始化所有source很容易踩到reserved的寄存器地址。priority寄存器读写可能有对齐要求如果你的驱动用了非对齐访问在QEMU上能跑真芯片上可能总线报错。有些芯片实现里PLIC的中断上报还有一个“pending锁存”逻辑电平触发的源与沿触发的源行为不同。QEMU里可能只实现了最简单的电平上报真芯片上你要是没把外设的触发类型配成电平就可能出现中断一直挂起或一直清不掉的情况。这些点让我养成了一个习惯拿到新芯片手册先去看PLIC寄存器地图里source 0到最大source的完整列表把每个source对应到外设做成一张表。调试的时候这张表比什么都管用。3.4 优先级翻转怎么处理阈值、屏蔽、软中断PLIC不原生支持ISR抢占因此在实现“低优先级任务占用CPU时高优先级中断需要等待”这类场景时要尤其小心。比如你的系统里有低频高优的紧急事件也有高频低优的数据流中断。数据流中断一旦进入ISR且不打开嵌套就会长时间占用CPU高优紧急事件只能排队等。我常用的处理办法有几个在ISR入口判断当前是否有更高优先级中断pending。怎么判断直接读PLIC的pending寄存器看一下高优source的bit是否置位。如果置位就先不处理低优源立刻完成claim/complete写回、退出ISR让PLIC重新仲裁并上报高优中断。这等于用软件轮询模拟了一种快速抢占。把threshold动态调高。在处理关键代码段时把PLIC的threshold临时抬高到某个值屏蔽掉一批低优先级中断只允许超高优先级中断通过。退出关键段后恢复threshold。这个做法比较粗暴但非常有效特别适合不能容忍低优中断抖动的地方。用软件中断串联。某些复杂系统里低优中断ISR只做claim和状态记录真正的处理放到软件中断或者任务上下文去执行让ISR本身极其短小这样高优中断即使不抢占也能有足够的响应空间。4. APLIC进来之后域、IDC和免claim模式到底改了什么4.1 从PLIC走向APLIC规范演进背后的痛点PLIC的设计在上个十年里被广泛使用但它在一些新场景下逐渐显得吃力。最明显的两个痛点一个是多核系统的中断分发不够灵活。PLIC虽然支持多个target但中断源到target的映射通常要靠使能寄存器手工配置而且没有“域”的概念没法方便地把一组中断源整体交给一个安全域或虚拟机。另一个是中断处理的交互模式过于单一。claim/complete这套交互虽然解决了竞态但每次中断处理都要做一次MMIO读、一次MMIO写在中断频率很高的场景下开销不小。RISC-V后来在AIAAdvanced Interrupt Architecture规范里引入了APLICAdvanced Platform-Level Interrupt Controller专门用来替代PLIC。它的名字仍然带PLIC但内部设计思路已经有了很大变化。4.2 域和IDC多核系统里的中断归属如何重新界定APLIC里最重要的概念是“域”Domain。一个域可以包含一部分中断源以及一个或多个目标也就是CPU的某种中断文件。域之间是隔离的源一旦归属于某个域就不能再被其他域看到。这跟PLIC里“每个源有一个优先级、某个target使能某个源”的平面化模型不一样。每个域内部有中断传递控制IDCInterrupt Delivery Control。IDC负责和CPU本地中断控制器交互。在直送模式下APLIC可以直接把某个中断源对应的中断请求发送给指定hart的指定中断类型比如发送到M模式的外部中断或者S模式的外部中断。它不再像PLIC那样通过一个统一的外部中断引脚把笼统的“外部中断”发给CPU而是让每个源可以精确送到对应CPU核的对应特权模式。这种机制的优先级含义发生了变化APLIC本身在直送模式下其实不承担全局优先级仲裁。它更像一个“分发器路由表”把每个中断源按配置送到目标核。至于优先级由每个核的本地中断控制系统去决定。这个变化如果你还按PLIC的思路去理解就会觉得APLIC“没有优先级”实际上它的优先级被下放到本地化了。4.3 免claim模式去掉claim/complete后优先级还怎么排APLIC的直送模式里有一个让老PLIC驱动开发者眼前一亮的特性可以不使用claim/complete也就是免claim模式。每个中断源在触发后直接作为一条中断信号送到目标CPU核的外部中断入口。CPU核的本地中断控制器会把它当作一个普通的外部中断来处理。那怎么知道是哪个源触发的两种办法一种是每个中断源都独立映射到核的向量表CPU跳转到不同入口另一种是读APLIC提供的中断状态寄存器软件自己判断是哪个源。前者更接近向量中断后者则有点像古老的轮询。免claim模式对优先级排布的影响是PLIC时代的“全局选一个最高优先级的源再上报”没有了。在APLIC直送模式下如果有两个源同时触发它们可能同时送达同一个CPU核。至于先响应谁要看核内本地中断控制器的设置和软件如何处理。如果你的代码还是PLIC那套习惯——等一次中断读claim寄存器期望它只返回最高优先级那个源——在免claim模式里就会失灵因为根本没有claim寄存器给你读。这并不意味着APLIC没有优先级机制。在AIA完整方案里APLIC常常配合IMSIC使用IMSIC能够给中断传递提供基于内存中断文件MSI文件的机制支持非向量和向量中断并定义了中断优先级比较、抢占等行为。也就是说优先级仲裁的职责进一步往“每个核本地的中断文件”下沉。对软件开发者而言要处理的中断入口和优先级配置点也随之变了。4.4 APLIC与PLIC在优先级语义上的关键区别我整理了一下两者在优先级语义上的核心区别以下这几点是迁移时最需要关注的PLIC的优先级是全局的所有源汇聚到PLIC后统一仲裁APLIC直送模式下各个源按域直接分发优先级主要在核侧和IMSIC侧体现。PLIC靠priority大于threshold来判断一个源是否值得上报APLIC直送模式下域的使能和源的有效性决定是否发送本地中断控制寄存器再决定外部中断是否被CPU响应。PLIC的claim/complete天然形成了“一次只交给CPU一个中断源”的串行语义APLIC免claim模式下多个源可以同时到达软件需要做额外处理。PLIC的目标是“核”CPU/hart级别APLIC的域可以更精细地控制中断归属在虚拟化和多操作系统隔离场景下优势明显。5. 优先级机制对照与迁移建议选PLIC还是APLIC5.1 一张表对照两种控制器的优先级语义我直接把两边在中断优先级相关维度上的差别列一张表方便大家保存查用对比维度PLICAPLIC直送模式全局仲裁有所有源统一仲裁弱化按域分发优先级主要在核侧/IMSIC优先级来源每个source的priority寄存器域配置核侧本地中断控制/IMSIC阈值有threshold寄存器无全局threshold靠核侧控制最优中断选择硬件自动选择最高优先级的pending源不自动挑选多个源可同时送达中断识别方式claim寄存器读出中断号中断状态寄存器/向量表处理完成确认写complete寄存器无统一complete源清除方式依赖实现多核隔离较弱需软件仔细配置target和enable强域天然隔离软件兼容性老驱动生态成熟需要适配AIA新规范5.2 从PLIC软件栈迁移代码上要改哪几处如果你手里有一套PLIC驱动现在要往APLIC迁移我建议按这几个顺序改代码能少掉不少头发。删掉所有claim/complete读写。你得先确认芯片的APLIC是否工作在免claim模式。如果是进入ISR后直接去读APLIC的中断状态寄存器找出触发的源。把优先级初始化改成“域配置核侧配置”。在PLIC里你是一个一个source去写priority在APLIC里你得先把source划归到正确的域再把域和IDC连到目标CPU。少了这一步优先级配得再漂亮中断也不会到核上。多渠道处理ISR嵌套。因为APLIC直送模式下多个源可以同时到达同一个CPU核ISR里要更谨慎地处理“读状态、清状态、处理、再读状态”这个循环避免漏掉同时来的源。检查中断类型。PLIC时代很多驱动默认用电平触发配合claim/complete机制自动清pending。APLIC的直送模式里源触发条件如果配成沿触发软件清状态的方式会完全不同这直接影响“中断只来一次”还是“反复触发”。5.3 选型时除了优先级还需要关注什么我见过不少人在选PLIC还是APLIC的问题上纠结半天其实大部分情况下没得选芯片SoC出厂用哪个控制器你作为开发者的选择空间很小。真正要选型的情况通常发生在你自己设计RISC-V核SoC或者评估IP的时候。那时候我建议从这几个角度想需要多核安全隔离吗需要多个操作系统跑在不同核上那就倾向APLIC域机制能省很多软件功夫。既有软件栈是不是已经用PLIC写好了如果只是一颗简单的单核MCU外设中断也不多PLIC完全够用没必要为了新而新。中断频率高不高高频率中断场景下APLIC的免claim/MSI模式能减少MMIO读写次数如果只是几个低速外设PLIC的claim/complete开销无足轻重。开发工具链和调试器支持得怎么样实话说很多调试器对PLIC的寄存器识别比APLIC成熟得多APLIC在复杂域配置下调试起来更依赖日志和自写脚本。6. 实测中的优先级坑从“中断不响应”到“优先级不生效”6.1 排查“该来的中断一直不来”先给一个我非常常用的排查链路。当某个外设中断源始终不触发时我不建议上来就查PLIC的priority。先按下面几步走确认外设的中断条件真的产生了。很多时候是外设配置没到位比如UART的接收中断使能没开。确认外设的IRQ线确实拉高了。用逻辑分析仪或者示波器直接看SoC的IRQ输出引脚一锤定音。确认中断源在PLIC里的enable位为1。这一步看着简单但enable寄存器往往是多位分组有时寄存器偏移算错了就错开了整个bank。确认该源对应的priority大于当前threshold。我前面说过等于threshold也不行。确认CPU核的mie寄存器里对应外部中断使能位开了且mstatus.MIE是1。确认异常委托没有把该中断委托到一个没开使能的特权模式。比如你希望S模式处理但mideleg没配好中断留在了M模式而M模式又没有处理程序就会出现死寂。这个链路走完八成能找到问题。我这里要特别强调PLIC的priority只在步骤4里起效。很多人一上来就怀疑优先级配置浪费了几个小时结果问题是出在外设使能上。6.2 优先级配好了却没效果别忽略全局使能和核级状态还有一种常见情况外部中断能触发但是调高优先级之后响应顺序完全没变。这看起来像是优先级没生效其实往往是“全局使能和核级中断状态”把优先级机制架空了。举个例子你的ISR里长期开着mstatus.MIE全局中断允许嵌套。那么哪怕PLIC有优先级的裁定软件如果不检查PLIC上报的是不是高优源直接一股脑处理也会让配置看起来无效。还有可能是你在ISR里没有重新读取PLIC的claim寄存器而是用了“上次保存下来的中断号”去服务这类代码Bug我见过太多次。另外一个非常隐蔽的点PLIC的仲裁行为只发生在“PLIC向CPU发送请求”的那一刻。若低优先级中断已经通过claim被确认了PLIC会认为“这个中断正在被处理”不会再拿它跟新到来的高优先级中断比较。如果你期望高优先级中断能够立刻打断正在处理低优先级中断的ISR就必须在ISR中显式地重新打开全局中断或者在退出低优先级ISR前快速重claim一次。硬件不会自动帮你切换服务对象。6.3 多核场景下的目标中断的隐性坑多核RISC-V里PLIC的target是hart级别。这意味着你在核0上初始化PLIC时很可能碰到的坑是中断源enable配好了priority也大于threshold了但目标没选对导致核1收到了中断而你的中断服务程序却注册在核0上。现象就是中断“凭空消失”或者卡在一个看起来毫不相干的核上。APLIC里域的配置让这种问题更容易排查因为域的route关系更明确。但APLIC也有自己的坑域里有多个IDC时你要确认每个IDC对应的hart和特权模式是否匹配。我在一个RISC-V核设计项目里就遇到过APLIC把中断送给了S模式的stvec但S模式的stvec还没来得及初始化中断一进来就跳山系统直接复位。6.4 快速验证优先级配置是否生效这种问题与其靠猜不如直接做一次可控实验。我的做法是写一个测试函数同时触发两个中断源人为让它们间隔几个周期先后到达然后观察ISR被CPU记录的进入顺序。具体来说先把两个源的priority分别配成低和高。在ISR入口处读一个硬件周期计数器比如mcycle记录当前中断源编号和时间戳。同时触发两个源。打印或保存这两条时间戳顺序应该和priority设置一致。如果顺序不对再检查是不是threshold设得过高把某个源挡了或者enable位没配好。这个实验配合CLI日志能让你在五分钟内定位优先级配置是不是真的生效了。7. 配置一套可落地的优先级方案附C代码思路7.1 裸机初始化顺序先控制器后核侧无论PLIC还是APLIC我建议的初始化顺序都是“先外设、再控制器、最后核侧”。这个顺序的目的是避免中断在控制器还没配好的时候就冲到核上。通用顺序如下配置外设屏蔽外设中断确保IRQ线不要提前拉高。初始化PLIC/APLIC清零pending相关状态关闭所有source的enable把所有source priority设为默认值。逐个source配置priority和enable。配置控制器到核的关联关系PLIC的targetAPLIC的域/IDC路由。配置核侧清掉可能残留的pending设置好stvec或mtvec再打开核级外部中断使能。最后打开外设自己的中断使能。7.2 PLIC与APLIC的配置片段下面给一个非常精简的、直接可读的PLIC配置思路C语言函数形式#define PLIC_BASE 0x0C000000UL #define PLIC_PRIORITY(i) (PLIC_BASE 0x4 * (i)) #define PLIC_ENABLE(h) (PLIC_BASE 0x2000 0x80 * (h)) #define PLIC_THRESHOLD(h)(PLIC_BASE 0x200000 0x1000 * (h)) #define PLIC_CLAIM(h) (PLIC_BASE 0x200004 0x1000 * (h)) void plic_init_source(uint32_t source, uint32_t priority, uint32_t hart) { volatile uint32_t *prio (volatile uint32_t *)PLIC_PRIORITY(source); volatile uint32_t *en (volatile uint32_t *)PLIC_ENABLE(hart); volatile uint32_t *thr (volatile uint32_t *)PLIC_THRESHOLD(hart); *prio priority; // 0-15有效 *en | (1UL source); // 使能该source *thr 0; // threshold0放行所有优先级1的源 }这段代码的关键点是priority必须严格大于threshold所以threshold设为0时priority 1~15都会被放行。如果你把threshold设为7那priority 1~7的源全被挡住。另外某些PLIC实现里enable是32位分组source编号超过31时要跳到下一个使能寄存器。APLIC的直送模式配置思路稍微复杂一点因为涉及域和IDC。伪码示意如下#define APLIC_BASE 0x0D000000UL // 每个域的sourcecfg、domaincfg、IDC寄存器地址由芯片手册指定 void aplic_init_direct(uint32_t domain, uint32_t target_hart) { // 1. 配置域控制寄存器选择直送模式 write32(APLIC_BASE DOMAINCFG(domain), DIRECT_MODE); // 2. 把具体中断源分配到该域 write32(APLIC_BASE SOURCECFG(source), DOMAIN_INDEX(domain)); // 3. 配置IDC把域和target_hart绑定 write32(APLIC_BASE IDC_CTRL(domain, target_hart), ENABLE); }请注意AIA规范里APLIC的寄存器布局非常丰富不同厂商的偏移可能不同。上面只是说明配置套路实际使用必须对着芯片手册的寄存器偏移来。7.3 RTOS场景FreeRTOS与RT-Thread下怎么处理优先级到了RTOS层面PLIC/APLIC的“硬件优先级”和RTOS的“任务优先级”是两套独立体系很多人会把它们搞混。一般建议是把实时性要求高的中断源配成PLIC高优先级。比如操作系统tick定时器若走外部中断尽量给一个仅次于紧急事件的中止优先级。普通外设中断配成中低优先级ISR里只做标志置位和数据搬运把耗时操作放到任务里。如果RTOS自带的驱动封装了PLIC操作别自己再去重复配置。FreeRTOS的port层通常有portYIELD_FROM_ISR机制前提是中断ISR不需要额外调用claim。如果你用了PLIC的claim/complete这部分要改到port层否则每次中断上下文的保存恢复都会不对。我实际在RT-Thread上适配过一颗带PLIC的RISC-V芯片最快的办法是把原始驱动里所有PLIC操作集中封装成三个函数plic_claim、plic_complete、plic_irq_enable然后在port层的ISR入口和出口统一调用。这样改起来最省心也不容易漏。7.4 配置完优先级后建议做哪些验证配完之后不要急着跑业务功能先做三个层面的验证单源验证只使能一个中断源触发一次确认ISR能进、能清、能正常退出。这一步能排除“ISR入口/出口上下文保存恢复”的问题。多源顺序验证触发两个不同优先级的源确认响应顺序与优先级一致。这块可以直接用我在6.4说的时间戳法。高负荷压测开一个高频中断源长时间跑观察有没有中断丢失、优先级较低的中断会不会饿死。低频高优中断饥饿通常出现在高频低优源持续触发且PLIC迟迟不释放的时候。如果你发现低优高优源都积压可以试试动态调整threshold或使用更短ISR的架构方案。中断优先级这东西没出问题的时候它像空气出了问题的时候它会让你怀疑整颗芯片都是坏的。实际上绝大多数问题都出在“谁在什么时候该处理哪个源”的配置错位上。把PLIC和APLIC的模型彻底搞明白把排查链路背下来很多玄学问题说到底都是逻辑问题。
