What is the Correct Trace Packets for an MRET-Exception-Exception Sequence #187
Comments
I don't think that the above sequence is possible in RISC-V. EX1 will clear mstatus.MIE which will prevent interrupt EX2 from being taken. Perhaps you're asking about this sequence which has a different mode for EX1:
Or this sequence where EX1 does go to M mode but it must have been an interrupt (to have a different vector from EX2) and EX2 must have been an exception (because MIE=0):
(The latter sequence needs vectored mode to avoid an infinite loop of exceptions. I think that the latter sequence is highly unlikely to happen in real life because the first instruction of an interrupt handler should generally not be getting an exception.) |
|
Ricardo,
You have made a mistake, which I have corrected in line below.
Iain
From: Ricardo Ramirez ***@***.***>
Sent: 03 January 2025 21:26
To: riscv-non-isa/riscv-trace-spec ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [riscv-non-isa/riscv-trace-spec] What is the Correct Trace Packets for an MRET-Exception-Exception Sequence (Issue #187)
I have a question about which packets are generated for a certain instruction sequence. This sequence is shown below:
* MRET to lower privilege mode
* EX1 (exception/interrupt on target of MRET taken to M-mode)
* EX2 (interrupt on EX1 handler address taken to M-mode)
* Handler (the handler for EX2)
In my understanding, this sequence is governed by the section shown below from the diagram found in the Efficient Trace for RISC-V specification (Version 2.0.3, April 19, 2024) Chapter 9, Figure 2. "Instruction delta trace algorithm."
image.png (view on web)<https://github.com/user-attachments/assets/45807664-a883-478c-b10b-fac65e837534>
Based on this diagram, here is what I think is generated for each of the instructions above:
* MRET: Next inst is exc_only -> issue format 0/1/2 packet
* EX1: Updiscon previous (yes) -> exc_only (yes) -> issue format 3.1, address of EX1 instruction, thaddr = 0, cause/tval of EX1
* EX2: Exception previous (yes) -> exc_only (yes) -> issue format 3.1, address of EX2 instruction, thaddr = 0, cause/tval of EX1
[Iain] Should be cause/tval of EX2
* Handler: Exception previous (yes) -> exc_only (no) -> Reported (no) -> issue format 3.1, address of Handler instruction, thaddr = 1, cause/tval of EX2
[Iain] Reported is 'yes' as the exception on the previous cycle has been reported already. As a result, the outcome here is to issue format 3.0
In my example, 3, format 3.1 packets are generated, and no 3.0 packet. For the EX2 packet, with the color coding, the diagram indicates that the cause/tval are those for the previous exception (EX1), which means that the handler packet needs to be a 3.1 packet to convey the cause/tval for EX2. Unless the diagram coloring is wrong.
Have I understood the process correctly for this sequence?
-
Reply to this email directly, view it on GitHub<#187>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPST7CZYFMN2IRGICFCT2I356LAVCNFSM6AAAAABUSLTEHKVHI2DSMVQWIX3LMV43ASLTON2WKOZSG43DQMJZGQYTQNI>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>
|
|
@IainCRobertson Thanks for the correction. Regarding the packet generated on EX2. You said: "Should be cause/tval of EX2". The action box shows cause/tval in orange which means it should send cause/tval from previous exception. Is the color wrong in the diagram? |
|
Ricardo,
Actually I think the flow diagram isn't covering all the cases. Annoying as it took quite a while to figure out how to represent the different options compactly without any crossing lines in a flow diagram! I'll have to think again...
The existing colouring is correct for the case where there are back to back exceptions that don't follow an updiscon. For example:
[some instruction]: next inst is exc_only -> issue format 0/1/2 packet
EX1: do nothing
EX2: exception_previous (yes) -> exc_only (yes) -> issue format 3.1, address of EX2, thaddr = 0, case/tval of EX1
Handler: exception_previous (yes) -> exc_only (no) -> reported (yes) -> issue format 3.0
The change required is another 'reported?' test after the exc_only test. So for the example above you get the same result (new test in green):
[some instruction]: updiscon_prev (no) -> next inst is exc_only (yes) -> issue format 0/1/2 packet
EX1: do nothing
EX2: exception_previous (yes) -> exc_only (yes) -> reported (no) -> issue format 3.1, address of EX2, thaddr = 0, case/tval of EX1
Handler: exception_previous (yes) -> exc_only (no) -> reported (yes) -> issue format 3.0
And for your example:
MRET: next inst is exc_only -> issue format 0/1/2 packet
EX1: updiscon_prev (yes) -> exc_only (yes) -> issue format 3.1, address of EX1 instruction, thaddr = 0, cause/tval of EX1
EX2: exception_previous (yes) -> exc_only (yes) -> reported (yes) -> issue format 3.1, address of EX2, thaddr = 0, case/tval of EX2
Handler: exception_previous (yes) -> exc_only (no) -> reported (yes) -> issue format 3.0
Iain
From: Ricardo Ramirez ***@***.***>
Sent: 07 January 2025 02:02
To: riscv-non-isa/riscv-trace-spec ***@***.***>
Cc: Robertson, Iain (DI SW EDA DDCP TST RD EAH) ***@***.***>; Mention ***@***.***>
Subject: Re: [riscv-non-isa/riscv-trace-spec] What is the Correct Trace Packets for an MRET-Exception-Exception Sequence (Issue #187)
@IainCRobertson<https://github.com/IainCRobertson> Thanks for the correction.
Regarding the packet generated on EX2. You said: "Should be cause/tval of EX2".
The action box shows cause/tval in orange which means it should send cause/tval from previous exception. Is the color wrong in the diagram?
-
Reply to this email directly, view it on GitHub<#187 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSVEWHFCL57FW6F27RT2JMYPZAVCNFSM6AAAAABUSLTEHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZUGI2DQNRYGE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
Thanks for identifying a needed change to the flowchart. I'm wondering if the flowchart needs another change: Some of the lines from your examples say "do nothing", I do not see that path in the flowchart. Should I be interpreting the green decision box - 'Next inst is exc_only, ppccd_br, or unqualifed?' - as actually saying 'Next inst is exc_only and current inst is not exc_only, or ppccd_br or unqualifed" or should there be a 'Reported?' decision box afterwards? I can't find a path for "do nothing" unless I add on to the meaning of that decision box. |
|
Ricardo,
"Do nothing" is what happens if all the decisions take you out of the bottom of the diagram. So all the diamonds from "exception previous" downwards on the left-hand side of the flow diagram exit to the bottom. This was the case for the EX1 in the example I gave.
Iain
From: Ricardo Ramirez ***@***.***>
Sent: 07 January 2025 18:44
To: riscv-non-isa/riscv-trace-spec ***@***.***>
Cc: Robertson, Iain (DI SW EDA DDCP TST RD EAH) ***@***.***>; Mention ***@***.***>
Subject: Re: [riscv-non-isa/riscv-trace-spec] What is the Correct Trace Packets for an MRET-Exception-Exception Sequence (Issue #187)
@IainCRobertson<https://github.com/IainCRobertson>
Thanks for identifying a needed change to the flowchart. I'm wondering if the flowchart needs another change:
Some of the lines from your examples say "do nothing", I do not see that path in the flowchart. Should I be interpreting the green decision box - 'Next inst is exc_only, ppccd_br, or unqualifed?' - as actually saying 'Next inst is exc_only and current inst is not exc_only, or ppccd_br or unqualifed" or should there be a 'Reported?' decision box afterwards?
I can't find a path for "do nothing" unless I add on to the meaning of that decision box.
-
Reply to this email directly, view it on GitHub<#187 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSWLTLORX7P3MHW3CR32JQN57AVCNFSM6AAAAABUSLTEHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZVHE4TCNRUGA>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
I must be interpreting something wrong. For the example below (taken from an earlier example you provided). When I follow the flowchart for EX1 - when I get to the green 'Next inst is exc_only, ppccd_br, or unqualified?' diamond, I see that the instruction following EX1 - EX2 - has an exception. So, it seems to me that the answer to the question "is next inst exc_only" is "Yes". But, based on your response, it sounds like it should be "No". Am I misunderstanding what "exc_only" means? [some instruction]: next inst is exc_only -> issue format 0/1/2 packet |
|
Ricardo,
You're not misunderstanding - you've found another inaccuracy in the diagram. There is an unstated implication in the green diamond that the current instruction is not an exception.
The 'yes' exit from the green diamond should only occur on the retiring instruction before an exception. The condition in the diamond doesn't explicitly include this, and when there is only a single exception (the normal case) it is not necessary. The fact that it is necessary to be explicit for back to back exceptions was missed.
I'll fix.
Iain
From: Ricardo Ramirez ***@***.***>
Sent: 07 January 2025 19:43
To: riscv-non-isa/riscv-trace-spec ***@***.***>
Cc: Robertson, Iain (DI SW EDA DDCP TST RD EAH) ***@***.***>; Mention ***@***.***>
Subject: Re: [riscv-non-isa/riscv-trace-spec] What is the Correct Trace Packets for an MRET-Exception-Exception Sequence (Issue #187)
I must be interpreting something wrong. For the example below (taken from an earlier example you provided). When I follow the flowchart for EX1 - when I get to the green 'Next inst is exc_only, ppccd_br, or unqualified?' diamond, I see that the instruction following EX1 - EX2 - has an exception. So, it seems to me that the answer to the question "is next inst exc_only" is "Yes". But, based on your response, it sounds like it should be "No". Am I misunderstanding what "exc_only" means?
[some instruction]: next inst is exc_only -> issue format 0/1/2 packet
EX1: do nothing
EX2: exception_previous (yes) -> exc_only (yes) -> issue format 3.1, address of EX2, thaddr = 0, case/tval of EX1
Handler: exception_previous (yes) -> exc_only (no) -> reported (yes) -> issue format 3.0
-
Reply to this email directly, view it on GitHub<#187 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSTOQUKSUVELTPPMKOL2JQU55AVCNFSM6AAAAABUSLTEHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZWGA4TGMBYGE>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
Thanks for clarifying things for me. I look forward to seeing the updated flowchart. I think these are the changes that you identified:
|
|
Please review #198 |
I have a question about which packets are generated for a certain instruction sequence. This sequence is shown below:
In my understanding, this sequence is governed by the section shown below from the diagram found in the Efficient Trace for RISC-V specification (Version 2.0.3, April 19, 2024) Chapter 9, Figure 2. "Instruction delta trace algorithm."
Based on this diagram, here is what I think is generated for each of the instructions above:
In my example, 3, format 3.1 packets are generated, and no 3.0 packet. For the EX2 packet, with the color coding, the diagram indicates that the cause/tval are those for the previous exception (EX1), which means that the handler packet needs to be a 3.1 packet to convey the cause/tval for EX2. Unless the diagram coloring is wrong.
Have I understood the process correctly for this sequence?
The text was updated successfully, but these errors were encountered: