Incorrect Exception Priority

[roman-de-santos]

Working on Ssstrict Csr test for supervisor mode and accidentally included the satp register. This caused a strange exception and led to a mismatch between IDV and Wally. According to the Priv spec exception code 4 should be returned when Zicclsm is not enabled.

This occurs when lh x5,0(x5) is executed at address 0x800001c4 in the included elf file. 0x5 contains value 0xffffffff since on instruction address 800054a4 the csr 0x2a test loaded -1 into a random register which happened to be x1 (ra). Then there was an instruction access faulty exception on instruction 0x80007a14 while testing csr 0x174. This IAF exception caused ra (holding all 1s) to replace the value in mepc. When instruction 0x800001c4 in the traphandler (lh x5,0(x5)) was executed, this misaligned and access fault address caused an exception. Wally classified this as a load access fault but IDV classified this as a load address misaligned.

Running the SsstrictCsrS.elf file should replicate this error. Make sure satp is not skipped in addins/cvw-arch-verif/bin/csrtest.py
(line 207 of csrtest.py is csrtests(pathname, sCsrSkip + uCsrSkip + [0x180] ) # 0x180 is the satp register).

SsstrictCsrS.elf.gz

[jordancarlin]

Interesting one. From section 3.1.15 of the spec:

Load/store/AMO address-misaligned exceptions may have either higher or lower priority than load/store/AMO page-fault and access-fault exceptions.

The relative priority of load/store/AMO address-misaligned and page-fault exceptions is implementation-defined to flexibly cater to two design points. Implementations that never support misaligned accesses can unconditionally raise the misaligned-address exception without performing address translation or protection checks. Implementations that support misaligned accesses only to some physical addresses must translate and check the address before determining whether the misaligned access may proceed, in which case raising the page-fault exception or access is more appropriate.

So technically either exception is valid, but since rv32gc does not support misaligned accesses anywhere, it makes more sense to throw a misaligned exception.

[davidharrishmc]

Yes, the language encourages our rv32gc configuration with no Zicclsm to unconditionally raise the misaligned-address exception. That could happen without doing any address translation, if we want, but I think it’s harmless to leave the translation if that is easier.

…

On Apr 8, 2025, at 10:11 PM, Jordan Carlin ***@***.***> wrote: jordancarlin left a comment (openhwgroup/cvw#1350) Interesting one. From section 3.1.15 of the spec: Load/store/AMO address-misaligned exceptions may have either higher or lower priority than load/store/AMO page-fault and access-fault exceptions. The relative priority of load/store/AMO address-misaligned and page-fault exceptions is implementation-defined to flexibly cater to two design points. Implementations that never support misaligned accesses can unconditionally raise the misaligned-address exception without performing address translation or protection checks. Implementations that support misaligned accesses only to some physical addresses must translate and check the address before determining whether the misaligned access may proceed, in which case raising the page-fault exception or access is more appropriate. So technically either exception is valid, but since rv32gc does not support misaligned accesses anywhere, it makes more sense to throw a misaligned exception. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread. <#1350 (comment)> <https://github.com/notifications/unsubscribe-auth/AR4AA365DUOATV52KXIDSJT2YSTX3AVCNFSM6AAAAAB2X45SCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBYGI4TQMJVGM> jordancarlin left a comment (openhwgroup/cvw#1350) <#1350 (comment)> Interesting one. From section 3.1.15 of the spec: Load/store/AMO address-misaligned exceptions may have either higher or lower priority than load/store/AMO page-fault and access-fault exceptions. The relative priority of load/store/AMO address-misaligned and page-fault exceptions is implementation-defined to flexibly cater to two design points. Implementations that never support misaligned accesses can unconditionally raise the misaligned-address exception without performing address translation or protection checks. Implementations that support misaligned accesses only to some physical addresses must translate and check the address before determining whether the misaligned access may proceed, in which case raising the page-fault exception or access is more appropriate. So technically either exception is valid, but since rv32gc does not support misaligned accesses anywhere, it makes more sense to throw a misaligned exception. — Reply to this email directly, view it on GitHub <#1350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA365DUOATV52KXIDSJT2YSTX3AVCNFSM6AAAAAB2X45SCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBYGI4TQMJVGM>. You are receiving this because you are subscribed to this thread.