Update Smrnmi to account for Smdbltrp extension #1248
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gfavor
reviewed
Feb 29, 2024
gfavor
reviewed
Feb 29, 2024
This is a backwards compatible change to support resumable double traps within M-mode when both extensions are implemented. Although the resumability feature is not terribly interesting, the reuse of the Smrnmi state for M-mode double traps aids debugging (and fault diagnosis for the hardware-error exception case).
aswaterman
force-pushed
the
smrnmi-smdbltrp
branch
from
1b7861c to
10700d0
Compare
|
Note: The last sentence still refers to the Smdbltrp exception instead of
the Smdbltrp extension.
…On Thu, Feb 29, 2024, 3:39 PM Andrew Waterman ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/rnmi.adoc
<#1248 (comment)>
:
> @@ -71,9 +71,14 @@ of holding.
.Resumable NMI cause `mncause`.
include::images/bytefield/mncause.edn[]
-The `mncause` CSR holds the reason for the NMI, with bit MXLEN-1 set to
-1, and the NMI cause encoded in the least-significant bits or zero if
-NMI causes are not supported.
+The `mncause` CSR holds the reason for the NMI.
+If the reason is an interrupt, bit MXLEN-1 is set to 1, and the NMI
+cause is encoded in the least-significant bits.
+If the reason is an interrupt and NMI causes are not supported, bit MXLEN-1 is
+set to 1, and zero is written to the least-significant bits.
+If the reason is an exception within M-mode that results in a double trap as
+specified in the Smdbltrp exception, bit MXLEN-1 is set to 0 and the
+least-significant bits are set to the exception cause code.
I went back and forth, but I think I found a phrasing that is
comprehensible to people who haven't read the other spec.
—
Reply to this email directly, view it on GitHub
<#1248 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALLX6GWEP2YIZZHGPBUGDOLYV653VAVCNFSM6AAAAABD67ZT7KVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMJQGA2TOOJYGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Are you looking at the old version somehow? It looks right to me (although apparently I'm dyslexic with respect to these words, so I'm not a reliable witness). |
|
Right now I'm only on a phone and can only see the text included in the
email from GitHub - which apparently is not showing the latest changes that
you're describing. Later I'll check properly from my laptop and presumably
will see everything looking hunky dory. :)
Greg
…On Thu, Feb 29, 2024, 4:07 PM Andrew Waterman ***@***.***> wrote:
Are you looking at the old version somehow? It looks right to me (although
apparently I'm dyslexic with respect to these words, so I'm not a reliable
witness).
—
Reply to this email directly, view it on GitHub
<#1248 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALLX6GWLLLWYTRDCAGQEIM3YV7BEJAVCNFSM6AAAAABD67ZT7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZSGE4DGMZUHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Strange how github emails show changes, but apparently not these latest
changes. (I haven't noticed this before, but then again usually there
isn't change on top of change on top of an original change.) Now looking
at the changes directly within github, they look good.
Greg
…On Thu, Feb 29, 2024 at 4:12 PM Greg Favor ***@***.***> wrote:
Right now I'm only on a phone and can only see the text included in the
email from GitHub - which apparently is not showing the latest changes that
you're describing. Later I'll check properly from my laptop and presumably
will see everything looking hunky dory. :)
Greg
On Thu, Feb 29, 2024, 4:07 PM Andrew Waterman ***@***.***>
wrote:
> Are you looking at the old version somehow? It looks right to me
> (although apparently I'm dyslexic with respect to these words, so I'm not a
> reliable witness).
>
> —
> Reply to this email directly, view it on GitHub
> <#1248 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ALLX6GWLLLWYTRDCAGQEIM3YV7BEJAVCNFSM6AAAAABD67ZT7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZSGE4DGMZUHA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a backwards compatible change to support resumable double traps within M-mode when both extensions are implemented. Although the resumability feature is not terribly interesting, the reuse of the Smrnmi state for M-mode double traps aids debugging (and fault diagnosis for the hardware-error exception case).