Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial notes on trap handlers #84

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Add initial notes on trap handlers #84

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
127 changes: 127 additions & 0 deletions trap-handlers.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,127 @@
[[trap-handlers]]
== Machine-Level Interrupts and Exceptions

=== Delegation

A RISC-V Machine mode execution environment may delegate handling interrupts and exceptions to the Supervisor or Hypervisor mode execution environment.

For reference, see https://github.com/riscv/riscv-isa-manual/blob/main/src/machine.adoc#machine-cause-register-mcause[the definitions in the RISC-V ISA spec].

==== Interrupts
[%autowidth,float="center",align="center",cols=">,>,<",options="header",]
|===
| Code / Description |OpenSBI |oreboot SBI
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why reference m-mode implementations? Why not call out what the expected behavior should be? And we should probably include the reasoning.

Copy link
Author

@orangecms orangecms Oct 17, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is for reference now, based on this suggestion #83 (comment)

my pledge is to always delegate everything that S-mode could handle, which only excludes operations involving CSRs and possibly MMIO spaces that are M-mode accessible only, AIUI

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I had implied we should go into describing M mode implementations, that was not the intention. The BRS spec describes S mode behavior as it relates to booting at OS. Some implementations may not even have an M mode (think VMs).

We should come up with expected behavior (or a mechanism of conveying the necessary info). But I kinda wanna second Ved's feedback or why we ought to care - I think the assumption is that the OS will take the exception eventually for reasons that it would care about (even if the original exception went to M, as it very well might, for example due to firwmare-first error handling)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also went I mentioned "can we enumerate" I meant in the context of understanding the problem space, the github ticket, not actually enumerating in the spec. I definitely don't think this belongs in the spec itself.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"my pledge is to always delegate everything that S-mode could handle" we're definitely into impl-specific choices, and I don't think the BRS spec is the place to push for those choices. Like with other architectures, work-arounds and additional complexity may end up getting put into M, but in a manner generally transparent to S mode software. What matters is not what's done, but what's the measurable impact.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha. I had understood from this comment that BRS would supersede the platform spec:
riscvarchive/riscv-platform-specs#91 (comment)

So my intention was to get to a definition of behavior an S-mode OS would expect to avoid confusion where exceptions and/or interrupts are or are not arriving. That is what surprised me when Linux was not handling unaligned access traps, which is now being implemented in a pending patch series. Other OSes that are not part of that development history would benefit. Should this rather go into PRS, then? I would be happy to see it well-defined somewhere, not being picky where. BRS appeared to be closest to that from my current understanding. Where do you rather see it? It could also live in the wiki or in a blog post, I think.

For clarification: In which sense do you mean "transparent"?
There are two interpretations around:

  1. opaque, the other component (S-mode here) is not aware of something
  2. visible, the other component can notice and acknowledge

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, so basically you want a base set of exceptions that an S-Mode OS can expect to be delivered? (like unaligned access).

Will bring this up in the BRS call today and come back with some guidance.

|0 _Reserved_ +
1 Supervisor software interrupt +
2 _Reserved_ +
3 Machine software interrupt +
4 _Reserved_ +
5 Supervisor timer interrupt +
6 _Reserved_ +
7 Machine timer interrupt +
8 _Reserved_ +
9 Supervisor external interrupt +
10 _Reserved_ +
11 Machine external interrupt
12-15 _Reserved_ +
&#8805;16 _Designated for platform use_
| O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O
| O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O
|===

X = explicitly set
O = explicitly unset
I = initial value unchanged

==== Exceptions
[%autowidth,float="center",align="center",cols=">,>,<",options="header",]
|===
| Code / Description |OpenSBI |oreboot SBI
|0 Instruction address misaligned +
1 Instruction access fault +
2 Illegal instruction +
3 Breakpoint +
4 Load address misaligned +
5 Load access fault +
6 Store/AMO address misaligned +
7 Store/AMO access fault +
8 Environment call from U-mode +
9 Environment call from S-mode +
10 _Reserved_ +
11 Environment call from M-mode +
12 Instruction page fault +
13 Load page fault +
14 _Reserved_ +
15 Store/AMO page fault +
16-23 _Reserved_ +
24-31 _Designated for custom use_ +
32-47 _Reserved_ +
48-63 _Designated for custom use_ +
&#8805;64 _Reserved_
|O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O
|O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O +
O
|===