Implicit reads of JVT

[Silabs-ArjanB]

The specification states that the JVT CSR requires a state enable to be allocated (within the Smstateen extension I would assume).

The specification furthermore states:

Additional architectural state requires a state enable to be allocated. Accesses when the state is disabled will
throw an illegal instruction exception. The state enable is not specified in this document.

I would assume that implicit reads of the JVT CSR (by executing table jump instructions) are not impacted in any way by this state enable bit. Can that be made explicit in the specification if you agree?

Note that the Smstateen specification states:

In some cases, the bits of the stateen CSRs will have a dual purpose as enables for the ISA extensions that introduce the controlled state.

I would also assume that the state enable related to the JVT CSR does not have such a dual purpose. Could that be made explicit in the specification as well if you agree?

Will the relevant Smstateen bit get specified in the Zc specification or will this require an update to Smstateen?

[tariqkurd-repo]

again - sorry for the slow reply.

If smstateen is not implemented then there is no impact on JVT, table jumps can be executed as expected.
If smstateen is implemented and the JVT bit is disabled then all access to JVT is prohibited, so no table jump instructions can execute and CSR instruction access to JVT faults.
If smstateen is implemented and the JVT bit is enabled then all access to JVT is permitted, so all table jump instructions can execute and CSR instruction access to JVT is permitted.

There will be no smstateen bit for the ISA extension itself, only for the JVT CSR. The smstateen bit needs documenting as part of the smstateen spec and not as part of the Zc spec.

that's my understanding, @aswaterman do you agree?

[Silabs-ArjanB]

Hello @tariqkurd , that seems very restrictive to me. For example in a machine with machine+user mode and smstateen implemented it would be nice if both machine mode and user mode can execute table jumps without giving user mode the right to modify (or even explicitly read) the JVT CSR.

[tariqkurd-repo]

Hi @Silabs-ArjanB , that's not the intention of Smstateen.

Malicious user code can destroy a user process in many different ways, it only needs to overwrite the stack pointer to break execution. The value of JVT is no different, it's one of many thing the user can accidentally overwrite.

It's much simpler to keep JVT part of the current context.

If you're worried about user mode breaking JVT for other contexts, well - it's saved and restored as part of the context so it's not a problem. When entering the interrupt handler to switch tasks it can be saved / restored along with the rest of the context.

Is there a problem with this?

[Silabs-ArjanB]

Hi @tariqkurd , there is no problem with your definition in itself. It is just that it is not what I had expected.

As quoted above the Smstateen specification states that "in some cases, the bits of the stateen CSRs will have a dual purpose as enables for the ISA extensions that introduce the controlled state.". I did simply not expect that Zc's stateen usage would get defined as also having this 'dual purpose'. If the Zc related stateen would only have effect on the explicit JVT CSR accesses, then we would actually use the related stateen bit. If the stateen bit also has the secondary effect that you described, then basically it implies it no longer makes sense to compile user mode code using table jumps (as these might not be permitted). Effectively we would have to implement the stateen bit (as the Zc spec states that "additional architectural state requires a state enable to be allocated") and then we just have to always set that bit to 1 (otherwise we cannot benefit from the code size savings related to table jumps for user mode code).

What is the benefit (or intended use case) of mandating the stateen bit for Zc if it is defined with the stated dual purpose?

[tariqkurd-repo]

Hi @Silabs-ArjanB I've started a thread on the privileged mailing list as I don't know the answer.

https://lists.riscv.org/g/tech-privileged/topic/smstateen_for_zcmt/91138714?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,91138714,previd%3D1652705739174036941,nextid%3D1632114780674276819&previd=1652705739174036941&nextid=1632114780674276819