Finalize sub-exception code reporting mechanism

[arichardson]

This is a question for ARC review.

In the current CHERI specification, we report an exception sub-code in mtval2/stval2/etc. The upside of this approach is that it does not impact other extensions, but the downside is that we add new CSRs that were not previously required just to report a few bits of extra information.

Would it be cleaner to reserve the high 8 or 16 bits of the *cause CSR to report this additional sub-cause? mcause >= 64 is reserved, so this could be possible? Thena CHERI-aware operating system could to check cause & 0xffffff in the trap handler and obtain the remaining information form cause & 0xff000000 instead of having to read the new *tval2 register.

This would also make it easier to reuse the software check exception code instead of the custom 0x1c (#60).

Original discussion: #379 (review)?

[davidchisnall]

In CHERIoT, we have a pending patch to the RTOS that does a mapping very like this for reporting to user code. Using the low bits would be a bit cleaner since it then makes the CHERI exceptions a range. Where you can check if it’s in the range with a single and and can then extract the CHERI cause with another one.

[arichardson]

I like the idea of using the low bits for the extra information. Right now mcause values > 64 are marked as reserved and we currently require 8 bits of mtval2 state (although only 4 bits are allocated so far).

If we want to keep reserving 8 bits of exception space we could say 512->1023 is reserved for CHERI, i.e. CHERI exception was triggered if mcause & 0x200 == 0x200.

[arichardson]

I just had a look at the CLIC spec and it appears it already adds sub-fields to mcause, so doing this for CHERI would also be consistent.

 mcause
 Bits   Field         Description
 XLEN-1 Interrupt     Set to 1 for interrupts and 0 for exceptions
 30     (reserved)    Contains minhv (AKA xinhv) bit when smclicshv extension present
 29:28  mpp[1:0]      Previous privilege mode, usually same as mstatus.mpp
 27     mpie          Previous interrupt enable, usually same as mstatus.mpie
 26:24  (reserved)
 23:16  mpil[7:0]     Previous interrupt level
 15:12  (reserved)
 11:0   exccode[11:0] Exception/interrupt code

The current privilege spec states that anything from 64 is reserved, i.e. only bits 5:0 are allocated. Seeing as there are already new fields allocated above the exception code, maybe the cleanest approach would be to allocate the free bits 15:12 as the sub-code that reports tag violation etc.? Not sure if this is cleaner than allocating lots of values in the excode region using the approach in the previous comment

[nwf]

AFAICT, the CLIC mcause values will always be interrupts and so have the Interrupt bit (at index XLEN-1) set, and CHERI traps will always be synchronous exceptions and so have that bit clear, and so there is no need to contort ourselves around its choice of bitfield layout.
Besides, even slimmed down to what's defined and not reserved for future expansion, the existing mtval2 bitfields amount to 2 (type) + 3 (cause) = 5 bits, which wouldn't fit in 15:12. I think I'd vote for the previous comment's suggestion.