You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In the NutShell implementation, the handling of the mtvec/stvec registers does not correctly clear the Mode's reserved second bit (bit 1) upon reading, as per the RISC-V specification. The specification states that the second bit of the mtvec register is reserved and should be read as zero. Furthermore, I reviewed the NutShell source code and confirmed that the reserved bit is not being used. However, NutShell's implementation only clears the least significant bit (bit 0) and incorrectly includes the second bit in the read value, leading to an incorrect reading of the mtvec value. Moreover, due to the lack of handling for bit 1, this bug will further result in the BASE field not being four-byte aligned.
According to Privileged Specification 3.1.7:
The value in the BASE field must always be aligned on a 4-byte boundary.
Overall, this implementation error results in at least two disturbances in the tvec register.
Set the mtvec register with a value where the second bit is set (e.g., 0xf).
Read the mtvec register value.
Observe that the read value incorrectly includes the second bit.
Additionally, check whether the BASE field is four-byte aligned.
Expected behavior
When reading the m/stvec registers, the value should have the reserved second bit cleared, returning a value where only the least significant bit (bit 0) is cleared as per the specification. The expected behavior is to always read the second bit as zero, ensuring compliance with the RISC-V specification.
Additional context
This issue potentially affects the compliance of the NutShell implementation with the RISC-V ISA specification and may lead to incorrect behavior in systems relying on accurate m/stvec registers handling.
The text was updated successfully, but these errors were encountered:
Describe the bug
In the NutShell implementation, the handling of the mtvec/stvec registers does not correctly clear the Mode's reserved second bit (bit 1) upon reading, as per the RISC-V specification. The specification states that the second bit of the mtvec register is reserved and should be read as zero. Furthermore, I reviewed the NutShell source code and confirmed that the reserved bit is not being used. However, NutShell's implementation only clears the least significant bit (bit 0) and incorrectly includes the second bit in the read value, leading to an incorrect reading of the mtvec value.
Moreover, due to the lack of handling for bit 1, this bug will further result in the BASE field not being four-byte aligned.
According to Privileged Specification 3.1.7:
Overall, this implementation error results in at least two disturbances in the tvec register.
Read mtvec.
NutShell/src/main/scala/nutcore/backend/fu/CSR.scala
Line 435 in 4bb506b
Clear the least significant bit of mtvec but ignore the second bit (bit 1).
NutShell/src/main/scala/nutcore/backend/fu/CSR.scala
Lines 655 to 656 in 4bb506b
To Reproduce
Steps to reproduce the behavior:
Expected behavior
When reading the m/stvec registers, the value should have the reserved second bit cleared, returning a value where only the least significant bit (bit 0) is cleared as per the specification. The expected behavior is to always read the second bit as zero, ensuring compliance with the RISC-V specification.
Environment:
OS: Ubuntu 22.04.3 LTS
Compiler: gcc 11.4.0
Additional context
This issue potentially affects the compliance of the NutShell implementation with the RISC-V ISA specification and may lead to incorrect behavior in systems relying on accurate m/stvec registers handling.
The text was updated successfully, but these errors were encountered: