Add S-mode shadow for debug CSRs

[AoteJin]

To align with RISC-V, the specification will add a set of S-mode shadows for the debug CSRs: dcsr, dpc, and dscratch*.

[pdonahue-ventana]

Can you explain why there would need to be S-mode shadows for those CSRs?

(Due to my own bandwidth limitations, I only partially pay attention to what's going on here so I might have missed a previous discussion about this.)

[AoteJin]

The external debug security spec adds constraints on the debugger, potentially limiting it to S-mode privilege only. In such cases, the debugger would lose access DCSR, DPC, DSCRATH*. Currently, the spec allows access to those CSRs in debug mode regardless privilege granted to the debugger. However, this approach is not very much aligned with RISC-V style, and we discussed in TG meeting to add a set of S-mode shadow for DCSR, DPC, DSCRATCH* to be more consistent.

[pdonahue-ventana]

Unfortunately, I have a conflicting meeting during the Tuesday TG meeting so I haven't been able to come.

My understanding is that if the debugger is limited to S-mode privilege then halting will still take you to Debug Mode. The debug spec says that in Debug Mode "All operations are executed with machine mode privilege, except that additional Debug Mode CSRs are accessible..." My assumption was that the external debug security spec would say something like "If Debug Mode is limited to S-mode privilege then all operations are executed with supervisor mode privilege, except that additional Debug Mode CSRs are accessible..." (I know that the top two bits of the CSR address encode the mode. However, that already doesn't apply to dcsr/dpc/dscratch*.)

My main concern is that I don't think that these registers should be accessible to an operating system. Maybe I'm missing a subtlety of the proposal. If the proposal is that the new CSRs are only accessible to the external debugger but (like with the current Sdext) not accessible when running normal S-mode or M-mode software then this is OK with me.

[AoteJin]

My main concern is that I don't think that these registers should be accessible to an operating system. Maybe I'm missing a subtlety of the proposal. If the proposal is that the new CSRs are only accessible to the external debugger but (like with the current Sdext) not accessible when running normal S-mode or M-mode software then this is OK with me.

Right, this update is not intended to extend the access scope of the debug CSRs, and none of them should be accessible outside of debug mode .
As you mentioned, one of the purpose is to simplify the implementation by leveraging the address based logic to regulate the CSR access from debugger.

[pdonahue-ventana]

none of them should be accessible outside of debug mode

Perfect. Then I have no objections.

[AoteJin]

PR #60 to submit the update

[AoteJin]

Close with PR merged.