[Bug Report] Incorrect exception type of PMP violation during address translation

[Phantom1003]

Our co-simulation framework found that the exception type of address translation PMP violation is incorrect.

In the following test case, we let a non-leaf (level 2) PTE out of the PMP range.
Next, we will perform a store operation with a special virtual address, during translation processor will try to access the PTE that does not match any PMP.
cva6 throws a load access fault, while spike throws a store access fault.

[cva6]  Exception @    119000, PC: 000000008000036c, Cause: Load Access Fault,
[cva6]                                 tval: 0000000080102008
[spike] core   0: 0x000000008000036c (0x00b52023) sw      a1, 0(a0)
[spike] core   0: exception trap_store_access_fault, epc 0x000000008000036c
[spike] core   0:           tval 0x0000000040201010
[spike] core   0: 0x0000000080000004 (0x34302f73) csrr    t5, mtval
[error] WDATA SIM 0000000040201010, DUT 0000000080102008
[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, cva6 should throw a store access fault.

cva6-9.zip

@ProjectDimlight helps reproduce the problem

[Moschn]

Thanks for reporting this.

I proposed a fix in #908. Can you try if this solves your issues?

[zarubaf]

Thanks @Moschn.
@Phantom1003 It would be really great if we could test the patch of @Moschn.

[Phantom1003]

Thanks, cva6 throws a correct Store Access Fault exception, but the *tval seems filled with the physical address instead of the virtual address:

Exception @    119000, PC: 000000008000036c, Cause: Store Access Fault,
                                tval: 0000000080102008
core   0: 0x000000008000036c (0x00b52023) sw      a1, 0(a0)
core   0: exception trap_store_access_fault, epc 0x000000008000036c
core   0:           tval 0x0000000040201010
core   0: 0x0000000080000004 (0x34302f73) csrr    t5, mtval
[error] WDATA SIM 0000000040201010, DUT 0000000080102008
[error] check board clear 30 error
[CJ]           0 integer register Judge Failed
    1204ns     1189 M 0000000080000004 0 34302f73 csrr           t5, mtval

The related verse in specification is:

When page-based virtual memory is enabled, mtval is written with the faulting virtual address, even for physical-memory access-fault exceptions.

[Moschn]

I just read this section of the spec and it seems to be a bit ambiguous. Yes mtval should contain the faulting virtual address, but which address is this exactly? Is this the virtual address that is being translated? or the address of the PTW that failed? I guess all accesses during a page table walk are to physical memory and thus the faulting address should be the initial virtual address.

I force pushed the fix to #908. Can you check if it passes your tests now?

[Phantom1003]

Yes, I agree with your understanding.
And the test case passed, cva6 and spike have the same behavior.
Thank you for your quick response, I will close this issue after the commit has been merged.