A vector of sideband signals to inform the trace output being stopped

[AoteJin]

Based on discussion on external debug security TG meeting, adding another bit alongside halted signal to bundle a vector is the desired way to inform the trace to stop output due to different reasons. The reserved encoding is for futural extension.

[new_bit, halted]	Tracing?	Stop reason
00	Yes	n/a
01	No	entering Debug Mode
10	No	due to security rules
11	No	reserved for future

[IainCRobertson]

I propose we call this signal ''notrace".

[bcstrongx]

Yeah, seems like bit 0 shouldn't be called halted anymore, since for the reserved 0b11 case we may not be halted. I might lean towards "traceinh[1:0]", but don't care that much.

One trick with this is that an implementation can't simply connect bit 0 to halted and bit 1 to security check failure. Otherwise the encoder could see 0b11 when the hart is both halted and security checks fail (e.g., we halted in M-mode but trace is not allowed in M-mode). The table above is clear enough, but the external debug spec probably needs clarification here.

[IainCRobertson]

Agree - we need a new name for the new vector, not a new signal that has an encoded meaning with halted. That’s a recipe for screw ups. I guess you’re thinking “trace inhibit”? I don’t think we need “trace” in the name of the ingress port signal - they’re all for trace! So we could just go with “inhibit”? I prefer that to traceinh as it’s not so obvious to the casual reader what “inh” means.

…

________________________________ From: Beeman Strong ***@***.***> Sent: Tuesday, June 4, 2024 6:14:25 PM To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW ICS TST RD EAH) ***@***.***>; Assign ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] A vector of sideband signals to inform the trace output being stopped (Issue #98) Yeah, seems like bit 0 shouldn't be called halted anymore, since for the reserved 0b11 case we may not be halted. I might lean towards "traceinh[1:0]", but don't care that much. One trick with this is that an implementation can't simply connect bit 0 to halted and bit 1 to security check failure. Otherwise the encoder could see 0b11 when the hart is both halted and security checks fail (e.g., we halted in M-mode but trace is not allowed in M-mode). The table above is clear enough, but the external debug spec probably needs clarification here. — Reply to this email directly, view it on GitHub<#98 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSWW2JNW5A3B2SDVUADZFXRWDAVCNFSM6AAAAABF6FFB6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBXHEZDAOJSHA>. You are receiving this because you were assigned.Message ID: ***@***.***>

[bcstrongx]

good point, inhibit works

[joxie]

Ping @IainCRobertson do we have a plan to add this to trace spec? We (nVidia team) can help to create a PR if needed.

[IainCRobertson]

Not a detailed one. In my view it should be part of the set of MRs submitted for ratification as part of the External Debug Security spec. E-Trace is a ratified standard, so this would be a normative change that will require significant scrutiny and sign-off. Needs to be properly coordinated. I'm happy to create the content but you need to agree the details of how to go about this with ARC beforehand.

[joxie]

Thanks for the response Iain. Agreed that it would be significant work since e-trace is ratified, I didn't realized that before. Feels like we can just use debug sec. spec to document the change, in that case we just need you to review, are you fine with that?

[IainCRobertson]

Happy to review. Work-around with existing ratified E-trace spec is to OR the signal that inhibits trace (I forget what it's called off the top of my head) into the HALTED ingress port signal. This at least should be mentioned in the External Debug Security spec.