Use software-check exception?

[sorear]

More of an ARC discussion item, maybe, but "violations of checks and assertions defined by ISA extensions that aim to safeguard the integrity of software assets, including e.g. control-flow and memory-access constraints. When this exception is raised, the xtval register is set either to 0 or to an informative value defined by the extension that stipulated the exception be raised" appears to be exactly what we need here, assuming the informative values can be properly allocated.

[tariqkurd-repo]

what exactly is this relating to?

[sorear]

§3.7.9 adds a new cause code and §3.7.11 defines tval data, but the new cause seems to be roughly the same as the existing (new since October) software check (18). The tval-split-into-fields is poorly consistent with other features of broader RISC-V.

[andresag01]

@sorear: Thanks for pointing this out! We did not see it because it was only introduced very recently and the pre-built versions of the privileged RISC-V spec do not have the change yet.

Its a really good point. I suspect that when going to the ARC with the CHERI proposal they will call for the CHERI extension to use the Software Check (18) mcause value that is described like this:

A Software Check exception is a synchronous exception that is triggered when there are violations of checks and assertions defined by ISA extensions that aim to safeguard the integrity of software assets, including e.g. control-flow and memory-access constraints. When this exception is raised, the xtval register is set either to 0 or to an informative value defined by the extension that stipulated the exception be raised. The priority of this exception, relative to other synchronous exceptions, depends on the cause of this exception and is defined by the extension that stipulated the exception be raised.

It would be good for the CHERI spec to re-use that Software Check code unless there is a big drawback. I am only concerned about how the xtval values are allocated when the implementation would like to support multiple extensions that write different, and hopefully not conflicting :crossed_fingers:, information to xtval.

The tval-split-into-fields is poorly consistent with other features of broader RISC-V.

This is true, but the RISC-V is not at all prescriptive of xtval. We've tried to pick minimal, although helpful, information to aid debugging, so I do not expect this to be a problem.

[sorear]

I am only concerned about how the xtval values are allocated

I asked on riscv/riscv-isa-manual@230bb413. We'll see.

[andresag01]

Thanks for asking that question. Reading the answers already there, it sounds that there is no table to avoid conflicts nor is there likely to be one for now, so we might just have to define something for CHERI and try getting feedback from the ARC. However, if we were to switch the CHERI spec to using Software Check, then the current xtval-split-into-fields idea will not fit well.

[jrtc27]

I would suggest just assigning each combination its own code, as is done with (instruction, load, store) * (access fault, page fault, alignment fault) for xcause in the base privileged spec. There's not really anything to be gained from having it split up into fields other than that you might as well if you can. It made more sense when the capability register responsible was encoded in xtval as well.

[andresag01]

We had discussions about this. It would be good to move the CHERI spec to use the new "Software Check" code, but ideally after that feature has been included in a formal RISC-V release and the xtval codes have been specified a little. Marking this as "future enhancement".

[jrtc27]

Note that there is a desire for xtval to contain the address corresponding to the attempted access in order to align with existing memory access exception types (see #379). This is not compatible with using the software-check exception, which instead uses xtval as a sub-code.