RT-Thread
[Bug] riscv interrupt could not be nested
RT-Thread Version
master
Hardware Type/Architectures
RISC-V with CLIC Interrupt
Develop Toolchain
GCC
Describe the bug
The interrupt handling logic for risc-v, see as below
https://github.com/RT-Thread/rt-thread/blob/fcd0b1e6797cbdca987f24d7c24a032709e5e53b/libcpu/risc-v/common/interrupt_gcc.S#L101-L109
In line 101, if another higher priority interrupt is nested(since in rt_hw_do_after_save_above, it will re-enable interrupt to allow higher priority interrupt), then it will switch from interrupt stack to task stack. I think if interrupt nesting is supported, it is better to nest in the interrupt stack to avoid corrupting the task stack.
Maybe here it should check whether interrupt is nesting or not to determine whether switch between interrupt stack and task stack.
Thanks
Other additional context
No response
As riscv porting code is maintained by @Yaochenger and @Rbb666, sorry to bother you by pinging you.
Answer me in Chinese is acceptable.
考虑移植稳定性与RV规范原生不支持中断嵌套，所以这里默认是不支持中断嵌套的，中断里面默认快进快出；当然在先辑半导体的SDK中关于RT-Thread实现了中断嵌套 可以查看一下
@Yaochenger
您好，能否明确指出他们移植代码的具体位置？我大致查看了 bsp\hpmicro\hpm6750evk2\startup\HPM6750\toolchains\gcc 目录下的移植情况，发现其似乎也是基于官方标准移植开展的工作，同样未考虑到这一要点。
就 RV 规范而言，并未明确规定中断不能嵌套。例如，在 CLIC 这类中断控制器下，中断是能够嵌套的；然而，采用 PLIC 中断控制器时则无法实现嵌套。鉴于 RT - Thread 属于实时操作系统，在 M 级别处理器上，中断嵌套的场景是极为常见的需求。因此，从专业角度来看，如果 RTT 提供标准移植，各 Vendor 负责完成自定义部分，那么对于中断可以嵌套的场景，应当考虑将其纳入考量范围，并研究是否能够进行优化。
感谢！
顺便咨询一下，这个 libcpu\risc-v\common\ 下的移植是否没有考虑到 SMP的场景，我移植适配的时候发现，会报下面的错误
C:/Software/NucleiStudio/toolchain/gcc/bin/../lib/gcc/riscv64-unknown-elf/14.2.1/../../../../riscv64-unknown-elf/bin/ld.exe: build\kernel\libcpu\risc-v\common\interrupt_gcc.o: in function `SW_handler':
C:\Work\Code\rt-thread\libcpu\risc-v\common/interrupt_gcc.S:77:(.text.entry+0x9c): undefined reference to `rt_thread_switch_interrupt_flag'
C:/Software/NucleiStudio/toolchain/gcc/bin/../lib/gcc/riscv64-unknown-elf/14.2.1/../../../../riscv64-unknown-elf/bin/ld.exe: C:\Work\Code\rt-thread\libcpu\risc-v\common/interrupt_gcc.S:91:(.text.entry+0xb6): undefined reference to `rt_interrupt_from_thread'
C:/Software/NucleiStudio/toolchain/gcc/bin/../lib/gcc/riscv64-unknown-elf/14.2.1/../../../../riscv64-unknown-elf/bin/ld.exe: C:\Work\Code\rt-thread\libcpu\risc-v\common/interrupt_gcc.S:101:(.text.entry+0xc6): undefined reference to `rt_interrupt_to_thread'
检查代码发现如下代码没有考虑SMP场景
https://github.com/RT-Thread/rt-thread/blob/fcd0b1e6797cbdca987f24d7c24a032709e5e53b/libcpu/risc-v/common/interrupt_gcc.S#L111-L129
最后请问下，目前有哪些riscv的bsp是支持了SMP版本的RT-Thread的
我理解是没有，但还需 RTT 大佬确认一下。
嗯嗯，请问 @Yaochenger @Rbb666 可以帮忙确认下，哪些BSP可以测试SMP版本，最好是有仿真器(Qemu)的。
我理解是没有，但还需 RTT 大佬确认一下。
嗯嗯，请问 @Yaochenger @Rbb666 可以帮忙确认下，哪些BSP可以测试SMP版本，最好是有仿真器(Qemu)的。
https://github.com/RT-Thread/rt-thread/blob/master/bsp/qemu-virt64-riscv/ 这个可以测试SMP
我理解是没有，但还需 RTT 大佬确认一下。
嗯嗯，请问 @Yaochenger @Rbb666 可以帮忙确认下，哪些BSP可以测试SMP版本，最好是有仿真器(Qemu)的。
哈喽，很抱歉现在才看到回复您，rt-thread在risc-v运行smp，这个在xuantie的c906 qemu上有示例，可以看一下xuantie的sdk，这里是一个参考链接： https://www.xrvm.cn/community/download?id=4478600198704140288
