External debug spec and Smmtt

[joxie]

It seems that the debug and trace control fields were renamed in the "RISC-V Supervisor Domains Access Protection" specification (e.g., SDEDBGALW to SEDA). Further, the control bits for the lower levels anyway do not exist there. I think it would be cleaner if the CSR and necessary fields for external debug and trace access control would be defined in this specification (with the new optional extensions it covers more use cases then supervisor domains). The "RISC-V Supervisor Domains Access Protection" specification could then just refer to the extension it requires and link the related control bits with msdcfg.{SEDA,SETA}.

Originally posted by @eknxp in #109 (comment)

[joxie]

I am still waiting for Ravi to comment feasibility to update Smmtt, leave this issue open

[gagachang]

@joxie It seems the latest "RISC-V Supervisor Domains Access Protection" specification has not yet added {SD|VS|US}EDBGALW/{SD|VS|US}ETRCALW fields.
https://lists.riscv.org/g/tech-arch-review/message/432

[andrewdellow]

Defining these bits in smmtt is not clean. They may be required in non-smmtt systems. The current smmtt specification requires implementation of more than just the msdcfg CSR - so as defined, there will not be an efficient, ratified way to get privilege level control of external debug in non-smmtt systems.

[andrewdellow]

It seems that the debug and trace control fields were renamed in the "RISC-V Supervisor Domains Access Protection" specification (e.g., SDEDBGALW to SEDA). Further, the control bits for the lower levels anyway do not exist there. I think it would be cleaner if the CSR and necessary fields for external debug and trace access control would be defined in this specification (with the new optional extensions it covers more use cases then supervisor domains). The "RISC-V Supervisor Domains Access Protection" specification could then just refer to the extension it requires and link the related control bits with msdcfg.{SEDA,SETA}.

Originally posted by @eknxp in #109 (comment)

agree

[mipsrobert]

@andrewdellow - I second your thoughts. It's very difficult to look at two specs at the same time - and if both are changing it is even harder ...

Now I see it has even longer history ...

I was thinking of raising this before, but as I missed several meetings, I thought it was all agreed and set in stone ...

IMO it would be better to define everything what is secure debug and trace related here (in this spec). The other spec may specify which bits (without even names!) are used for Secure D&T (as these in multi-purpose CSRs) but reference this spec, which should define these bits (names and meanings).

[joxie]

I agree, created riscv/riscv-smmtt#251 to request Smmtt to remove the descriptions and just reference external debug spec

[joxie]

PR #150 adds (tentative) bitfield definition