search

riscv / riscv-control-transfer-records

This repo contains a RISC-V ISA extension (proposal) to allow recording of control transfer history to on-chip registers, to support usages associated with profiling and debug.
https://jira.riscv.org/browse/RVG-62
Creative Commons Attribution 4.0 International
15 stars 4 forks source link

ARC feedback 2/13/24 and 2/20/24 #13

Closed bcstrongx closed 7 months ago

bcstrongx commented 7 months ago

From 2/13 ARC minutes:

CTR extension.  There was extensive discussion around whether depth of
buffer should be writable or trapped on guest access.  ARC noted there is a
virtualization hole in current design where if a guest OS can change the CTR
depth, it is known to not be virtualized.  ARC strongly recommends the
TG separates the depth field into a separate CSR.  If only a single
depth is supported by the implementation, no trap is required on a VS
write (WARL behavior) to depth.  If more than one depth is supported
in hardware and a VS-mode write is attempted, a trap is caused to
allow the more privileged mode to restrict the values the depth
register can be set to. This change would enable more forms of
recursive virtualization, and close the virtualization hole.

From 2/20 ARC minutes:

- Based on sctrstatus being just a 32-bit CSR (at CSR# 0x14F), 0x15F is assigned to the new sctrdepth CSR
- The ARC expects confirmation from the TG that it has decided to require S-mode; otherwise additional M-mode CSRs will be required solely for the case of S-mode not being present (which is not believed to be a practical usage scenario for CTR)
- The M-mode indirect CSRs can and should be eliminated (since M-mode can access through the S-mode indirect CSRs)
- After virtualization-related discussion about various options on trapping none/some/all VS-mode accesses to sctrdepth, all accesses should trap
- Discussed the non-requirement for supporting all depths lesser than the primary one(s) targeted by an implementation and agreed with the TG with not requiring support for all lesser depths
    - The spec should non-normatively note that some form of requirement along these lines may be specified by a platform spec
- Discussed and concluded that trapping of VS-mode accesses to sctrdepth should always happen - for consistency across implementations
    - Even for implementations that hardwire sctrdepth for one fixed Depth value (even though trapping is not truly needed for functional reasons in this case)
bcstrongx commented 7 months ago

See mailing list discussion of moving DEPTH field: https://lists.riscv.org/g/tech-control-transfer-records/topic/104474086#301