riscv-non-isa/riscv-arch-test

Handling Exceptions from MMode with MPRV=1

Opened this issue · 0 comments

The trap handler deals with xTVAL (and xEPC) relocation in order because of differing DUT vs reference model load points.
It does this be adjusting xTVAL by code/data/signature/test segment begin point VA. The handler has a data structure (maintained by the test) with the VA start points for each mode, selected using xSTATUS.xPP as the mode index.

This doesn't work if an access is made in Mmode when MPRV is set, because the trap is taken into Mmode, and therefore overwrites mstatus.mpp with Mmode, destroying the privilege mode information that the load/store used.
The bottom line: there is no architectural state available that can reconstruct what addressing mode the trapping access was in.
The hart knows it was made from Mmode, and knows either that it was some kind of access that was illegal in Mmode (possibly from PMP restrictions) or that it was made using access permissions from a lower mode - but not which (or if a )lower mode.

In general, Mmode must save that (and other ) missing information in order to properly handle the exception.
For ACT tests specifically, it could be done by saving the MPP value used by the trapping load/store, and using that instead of the copy in mstatus for determining the what should be used for MTVAL relocation when mstatus.MPRV==1;
nothing needs to be done for MEPC. This only needs to be done for Mmode traps.

To save tests some work, we can also check to see if the VM mode used by the trapping mode was bare, and force it to use the Mmode version (for all modes)

We should probably ensure that MPRV is clear in the RVTEST_CODE_END macro just to be safe