Preliminary support for trap handling during block emulation

[ChinYikMing]

Trap might occurs during block emulation, for example, page fault. In order to handle trap, we have to temporarily escape from block and jump to the trap handler to handle the trap PC by PC. Once trap is handled, resume the previous execution flow where cause the trap. To support this, we leverage setjmp function to store the state and a flag called is_trapped to indicate the emulation is in a trap handling mode currently. The sret and mret implementation are refactored to control the corresponding CSR before get out from trap.

Some S-mode CSRs are added to riscv_internal to support S-mode. S-mode, and M-mode CSR helper macros are also introduced, so that the CSR can be manipulated in an easier manner.

Related: #310

[jserv]

Benchmarks

Benchmark suite	Current: a4f6dab	Previous: a28615f	Ratio
Dhrystone	1476 Average DMIPS over 10 runs	1591 Average DMIPS over 10 runs	1.08
Coremark	1412.688 Average iterations/sec over 10 runs	1380.125 Average iterations/sec over 10 runs	0.98

This comment was automatically generated by workflow using github-action-benchmark.

[ChinYikMing]

For nested traps concern, I think before entering critical part of kernel control path, the contents of the CSR registers could be saved in the Kernel Mode stack, then restore the contents of the CSR registers when exiting the kernel control path. This way is considered as a software manner.

[jserv]

please do not merge yet

You can simply convert this pull request to draft, so that it will not be merged.

[ChinYikMing]

According to the "The RISC-V Instruction Set Manual ( Volume I: Unprivileged ISA Document Version 20191213 )", the execution environment interface ( EEI ) may or may NOT guarantee that misaligned loads and stores are fully supported. Thus, I think the emulator maybe no need handling misalignment in hardware manner and just let Linux handle it through exception. In other words, ensuring the emulator set the PC to correct address that stored in stvec CSR.

[jserv]

According to the "The RISC-V Instruction Set Manual ( Volume I: Unprivileged ISA Document Version 20191213 )", the execution environment interface ( EEI ) may or may NOT guarantee that misaligned loads and stores are fully supported. Thus, I think the emulator maybe no need handling misalignment in hardware manner and just let Linux handle it through exception. In other words, ensuring the emulator set the PC to correct address that stored in stvec CSR.

The reason rv32emu includes an option for misalignment handling is to align its behavior with Spike, allowing the two implementations to be compared. You should evaluate the minimal and necessary changes.

[ChinYikMing]

According to the "The RISC-V Instruction Set Manual ( Volume I: Unprivileged ISA Document Version 20191213 )", the execution environment interface ( EEI ) may or may NOT guarantee that misaligned loads and stores are fully supported. Thus, I think the emulator maybe no need handling misalignment in hardware manner and just let Linux handle it through exception. In other words, ensuring the emulator set the PC to correct address that stored in stvec CSR.

The reason rv32emu includes an option for misalignment handling is to align its behavior with Spike, allowing the two implementations to be compared. You should evaluate the minimal and necessary changes.

Got it. The current implementation of misaligned handling is through trap and set PC according to the stvec or mtvec CSR which in my expectation instead of handled by rv32emu itself. So that, the handling of misaligned behavior whether it results in a fatal error or is manageable depends on the implementation of the handler. Some simple test suites will be introduced to test the changes in this PR.

[jserv]

Shall we regard misalignment as a special case? Or, can it be generalized?

[ChinYikMing]

May I know what does the special case refer to?

[jserv]

May I know what does the special case refer to?

I meant to ask whether misalignment exceptions should be treated as one of the supported traps. If so, checks for misalignment exceptions should be implemented indirectly.

[ChinYikMing]

According to the entry.S of RISCV/Linux v6.1.112, it does support do_trap_load_misaligned and do_trap_store_misaligned. Thus, any misaligned load/store fault should be trapped into same path. In other words, trap_handler should be capable to handle the trap.

[jserv]

Add system emulation hook for GitHub Actions.

[ChinYikMing]

As I realizes that we may not need to enable exception or interrupt delegation from M-mode software to S-mode software since we do not tend to leverage the M-mode software ( such as OpenSBI ) to boot Linux kernel. Nonetheless, I would still like to include the medeleg and mideleg CSRs in the changes for a more comprehensive implementation. They are not entirely useless, as the test suite has utilized them from the very beginning of its design.

Any idea for this? @jserv

[jserv]

Nonetheless, I would still like to include the medeleg and mideleg CSRs in the changes for a more comprehensive implementation. They are not entirely useless, as the test suite has utilized them from the very beginning of its design.

I am afraid of the lack of proper test suite from CSR operations, meaning that we can have limited coverage. Meanwhile, I don't have explicit idea to escape from the chicken and egg problem.

[ChinYikMing]

According to the "The RISC-V Instruction Set Manual ( Volume I: Unprivileged ISA Document Version 20191213 )", the execution environment interface ( EEI ) may or may NOT guarantee that misaligned loads and stores are fully supported. Thus, I think the emulator maybe no need handling misalignment in hardware manner and just let Linux handle it through exception. In other words, ensuring the emulator set the PC to correct address that stored in stvec CSR.

The reason rv32emu includes an option for misalignment handling is to align its behavior with Spike, allowing the two implementations to be compared. You should evaluate the minimal and necessary changes.

The rv->is_trapped is compiled only when SYSTEM build flag is enabled. Thus, when comparing the misalignment handling between rv32emu and Spike during ISA simulation, the original behavior is maintained.

[ChinYikMing]

Nonetheless, I would still like to include the medeleg and mideleg CSRs in the changes for a more comprehensive implementation. They are not entirely useless, as the test suite has utilized them from the very beginning of its design.

I am afraid of the lack of proper test suite from CSR operations, meaning that we can have limited coverage. Meanwhile, I don't have explicit idea to escape from the chicken and egg problem.

I intend to remove the exception and interrupt delegation logic for now. We can add it back later if needed.

[ChinYikMing]

#498 must be merged first for this PR to pass the CI.

[vacantron]

Should it be (!ir->next IIF(RV32_HAS(SYSTEM))(|| rv->is_trapped, )) instead?

[ChinYikMing]

Should it be (!ir->next IIF(RV32_HAS(SYSTEM))(|| rv->is_trapped, )) instead?

Single | has same effect than double || since the all condition are boolean.

[vacantron]

The current semantics is equivalent, but I'm worrying about the support of nested interrupt handling in the future. The is-trapped might become a integer as a counter.

[ChinYikMing]

The current semantics is equivalent, but I'm worrying about the support of nested interrupt handling in the future. The is-trapped might become a integer as a counter.

If used as a counter, the implementation of sret should decrement is_trapped rather than simply setting it to false? Also, other places using is_trapped should increment it?

However, I'm curious in the current emulation, have you observed nested traps occurring, and do these changes need to be made to handle them?

[vacantron]

However, I'm curious in the current emulation, have you observed nested traps occurring, and do these changes need to be made to handle them?

In current, no (if I'm not mistaken). But we need it if we want to handle the page fault during handling the external interrupt, right?

[ChinYikMing]

However, I'm curious in the current emulation, have you observed nested traps occurring, and do these changes need to be made to handle them?

In current, no (if I'm not mistaken). But we need it if we want to handle the page fault during handling the external interrupt, right?

Indeed. However, we currently don't have a test suite for this situation. The best test suite would be the Linux kernel itself, and we might need an asynchronous mechanism (e.g., a signal thread) to periodically intercept the external interrupt.

For simplicity, I would prefer to keep track of this issue and address it only when it becomes necessary.

[jserv]

Refine the subject of this pull request according to the proposed changes.

[ChinYikMing]

The commits are reordered and squashed.

[vacantron]

To handle a trap, we temporarily exit the block and transfer control to the trap handler, processing each instruction by stepping.

Does this change explicitly break the chained block? or just trap into the interrupt service routine and go back to the current when it done?

[ChinYikMing]

To handle a trap, we temporarily exit the block and transfer control to the trap handler, processing each instruction by stepping.

Does this change explicitly break the chained block? or just trap into the interrupt service routine and go back to the current when it done?

The latter.