Description
Type of issue: bug report
Impact: unknown
Development Phase: proposal
Other information
Our co-simulation framework found that the exception type of address translation PMA violation is incorrect.
In the following test case, we modify a non-leaf (level 2) PTE to zero, which means the level 2 page dictionary is at 0x0000.
0x0000 is not part of the address range of the memory, which clearly violates the PMA.
boom throws a store page fault(0xf), while spike throws a store access fault(0x7).
[boom] 3 0x000000008000024c (0x0105051b) x10 0x0000000040201010
[spike] core 0: 0x000000008000024c (0x0105051b) addiw a0, a0, 16
[boom] 3 0x0000000080000004 (0x34302f73) x30 0x0000000040201010
[spike] core 0: 0x0000000080000250 (0x00b52023) sw a1, 0(a0)
[spike] core 0: exception trap_store_access_fault, epc 0x0000000080000250
[spike] core 0: tval 0x0000000040201010
[spike] core 0: 0x0000000080000004 (0x34302f73) csrr t5, mtval
[boom] 3 0x0000000080000008 (0x34202f73) x30 0x000000000000000f
[spike] core 0: 0x0000000080000008 (0x34202f73) csrr t5, mcause
[error] WDATA SIM 0000000000000007, DUT 000000000000000f
[error] check board clear 30 error
According to riscv-privileged specification:
If accessing pte violates a PMA or PMP check, raise an access-fault exception corresponding to the original access type.
Hence, boom should throw a store access fault.
Please tell us about your environment:
- version: ad64c54
@LuminaDCIX helps reproduce the problem
cc to @jerryz123