在RISC-V CLINT vector模式下，同步异常处理程序是否与ID=0中断处理程序（用户软件中断）相同？

Question

在RISC-V手册第二卷中，它说：

When MODE=Vectored, all synchronous exceptions into machine mode cause the pc to be set to the address in the BASE field, whereas interrupts cause the pc to be set to the address in the BASE field plus four times the interrupt cause number.

同步异常处理程序是否与ID=0中断处理程序（用户软件中断）相同？ 我尝试解决我关于 qemu-system-riscv64 virt 的问题，我的步骤如下，我尝试测试异常、用户软件中断和机器定时器中断：

# boot:
la t0, __vector_table
xor t0, t0, 1 # vector mode
csrw mtvec, t0

# vector table
__vector_table:
IRQ_0:
        j trap_handler_entry 
IRQ_1:
        j trap_handler_entry
             ...
IRQ_7:
        j timer_interrupt_vector_handler

# handler at vector table index 0
trap_handler_entry:
    SAVE_REGISTER
    j trap_handler # trap_handler is the handler 
                   # I used to handle all trap in direct mode
    RESTORE_REGISTER
    mret
# timer handler
void __atrributr__ ((interrupt)) timer_interrupt_vector_handler { 
    add new value in mtimecmp
}

此时我测试了ecall和timer interrupt，当timer interrupt和ecall发生时肯定会转到vector中的函数table，ecall -> INDEX=0，timer -> INDEX=7 然后我尝试触发用户软件中断，例如：

# Test function
while(1) {
    if (odd round) { ecall }
    else {
        set_csr(mip, USIP);
        /* Test func in M mode, enable USIE in MIE, 
         * and other interrupts works well */
    }
}

但是没有出现用户软件中断，说明书上说：

Each lower privilege level has a separate software interrupt-pending bit (SSIP, USIP), which can be both read and written by CSR accesses from code running on the local hart at the associated or any higher privilege level.

而且我确定我可以通过设置 MIP_SSIP 获得 Supervisor 软件中断。而且我查看了Spike中的interrupt raise函数，发现没有user softeware interrupt ...手册上也说：

If user-level interrupts are not supported, USIP and USIE are hardwired to zero.

所以我打印了 mie 来检查它：

# config in mie and mstatus
write_csr(mie, read_csr(mie) | MIP_MTIP | MIP_MSIP | MIP_SSIP | MIP_USIP);
write_csr(mstatus, (read_csr(mstatus) | MSTATUS_MIE | MSTATUS_SIE | MSTATUS_UIE));
# Set mie and mip in test func
set_csr(mie, MIP_USIP);
set_csr(mip, MIP_USIP);
# Result before and after set
MIE >> 000000000000008a # before
MIP >> 0000000000000000
MIE >> 000000000000008a # after
MIP >> 0000000000000000

USIP 和 USIE 硬接线为零！那么，也许现在没有 USI？但取决于第一次尝试，我认为同步异常实际上使用 ID=0 中断处理程序（用户软件中断）。看来我的问题的答案是肯定的......并且没有用户软件中断可以避免冲突？这是正确的吗？有冲突吗？

Answer 1

USIP 和 USIE 硬接线为零是一个实现细节。 第二卷：RISC-V 特权架构 V1.10 指出：

When vectored interrupts are enabled, interrupt cause 0, which corresponds to user-mode soft- ware interrupts, are vectored to the same location as synchronous exceptions. This ambiguity does not arise in practice, since user-mode software interrupts are either disabled or delegated to a less-privileged mode.

所以基本上答案是肯定的，同步异常处理程序与用户软件中断中断处理程序相同。

在RISC-V CLINT vector模式下，同步异常处理程序是否与ID=0中断处理程序（用户软件中断）相同？

In RISC-V CLINT vector mode, does the synchronous exception handler is same with the ID=0 interrupt handler(User software interrupt)?

interrupt

interrupt-handling

riscv