Add initial notes on trap handlers #84
Conversation
orangecms
force-pushed
the
trap-handlers
branch
from
19d9faa to
bfac9bc
Compare
Signed-off-by: Daniel Maslowski <[email protected]>
orangecms
force-pushed
the
trap-handlers
branch
from
bfac9bc to
b775492
Compare
| ==== Interrupts | ||
| [%autowidth,float="center",align="center",cols=">,>,<",options="header",] | ||
| |=== | ||
| | Code / Description |OpenSBI |oreboot SBI |
There was a problem hiding this comment.
Why reference m-mode implementations? Why not call out what the expected behavior should be? And we should probably include the reasoning.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
"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.
There was a problem hiding this comment.
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:
- opaque, the other component (S-mode here) is not aware of something
- visible, the other component can notice and acknowledge
There was a problem hiding this comment.
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.
|
@orangecms @adurbin-rivos should revisit this. |
Is there anything else to discuss? |
|
@orangecms can you rework this PR to reference the still in progress FWFT extension as a required mechanism? |
Finally getting back to wrapping my head aroubd this. So, in the end, I would remove the table/listing, and add the FWFT reference, correct? |
|
I think this item is waiting on SBI 3.0, then we can reference the FWFT. |
initial draft on #83
just give me a while, I'm not versed in ASCII doc yet