Added thread identifier (TID)

[francislaus]

Identifying threads is essential for CHERI compartmentalisation.

This will close #179

[tariqkurd-repo]

I've added them into my riscv-opcodes PR: riscv/riscv-opcodes#237

0xC80, "utid"
0x580, "stid"

and I suggest they are both non-reset

[francislaus]

I've added them into my riscv-opcodes PR: riscv/riscv-opcodes#237

0xC80, "utid" 0x580, "stid"

and I suggest they are both non-reset

The allocation looks good to me. I am not sure what you mean by "non-reset". Do you mean: undefined on reset as sscratchc for example? @tariqkurd-repo

[arichardson]

Would it make sense to have these be CLEN registers for added flexibility? Would allow S-mode to write a sealed cap into the register that can be unsealed by trusted user-mode code?

You can still use them as integer thread IDs, but now it's just a SW choice rather than a HW restriction.

[francislaus]

Would it make sense to have these be CLEN registers for added flexibility? Would allow S-mode to write a sealed cap into the register that can be unsealed by trusted user-mode code?

You can still use them as integer thread IDs, but now it's just a SW choice rather than a HW restriction.

This is a potential optimisation discussed in a bigger PR to the cheri-specification repo (CTSRD-CHERI/cheri-specification#123). Once you enter multiple levels of user-space compartmentalisation, the thread ID capability register would need to be checked every time whether it holds the correct capability. If not, the current compartmentalisation level needs to retrieve the correct capability, which would then work via the original TID, which you then do not have. Thus, you would need both the capability and the integer thread ID.

[tariqkurd-repo]

The allocation looks good to me. I am not sure what you mean by "non-reset". Do you mean: undefined on reset as sscratchc for example? @tariqkurd-repo

yes - undefined on reset

[tariqkurd-repo]

How about making this into a separate extension so we can mark it as work-in-progress like the PTE extension?

That way we can merge something sooner without accepting it into the base architecture.

[PeterRugg]

Looks good! (A few refs for UTID and STID possibly missing in the "CHERI Compartmentalization" section, but that's a very minor nit)

[arichardson]

Since the precise semantics are still experimental please factor it out to a separate extension.

[francislaus]

@jrtc27 @tariqkurd-repo @andresag01 @PeterRugg @arichardson

I have factored this out into a separate extension. Please let me know what you think.

[arichardson]

This overall looks good to me now - just two comments I'd like to see addressed before merging.

Also it might make sense to update the PR description with a bit more detail for the default squash+merge commit message.

[francislaus]

@arichardson Thank you, I have addressed your comments.

[arichardson]

Minor spelling issue otherwise LGTM