Add Smrnmi support - #16
Merged
Merged
Conversation
RNMI handlers use MNSCRATCH instead of MSCRATCH and need separate scratch space from regular trap handling. Add tmp1 for RNMI context while tmp0 remains for regular traps. Signed-off-by: Evgeny Voevodin <evvoevod@tenstorrent.com> Reviewed-by: Anup Patel <anup@brainfault.org>
Add CSR definitions (MNSCRATCH, MNSTATUS, MNEPC, MNCAUSE) and bit definitions (MNSTATUS_NMIE, MNSTATUS_MNPV, MNSTATUS_MNPP). Also add SBI_HART_EXT_SMRNMI to the hart extension enumeration. Signed-off-by: Evgeny Voevodin <evvoevod@tenstorrent.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Nylon Chen <nylon.chen@sifive.com>
Implement basic Resumable NMI (RNMI) handler support for the RISC-V Smrnmi extension. The new _trap_rnmi_handler assembly entry point saves context using the Smrnmi MN* CSRs (MNSCRATCH, MNEPC, MNSTATUS, MNCAUSE) and returns via mnret. It dispatches to sbi_trap_rnmi_handler(), which optionally calls a platform-specific ops->rnmi_handler callback for actual NMI processing. If no platform handler is registered or it fails, the event is reported as an unhandled NMI. The RNMI handler reuses the generic trap context structure but stores MN* CSR values (MNEPC, MNSTATUS, MNCAUSE) into the corresponding generic fields (mepc, mstatus, cause) for compatibility with existing trap infrastructure. Signed-off-by: Evgeny Voevodin <evvoevod@tenstorrent.com> Reviewed-by: Anup Patel <anup@brainfault.org>
… checks Smrnmi detection and enablement in the following commits will happen before any trap-based mechanism. As it relies on device tree, move sbi_platform_extensions_init() to the beginning of hart_detect_features(). Signed-off-by: Evgeny Voevodin <evvoevod@tenstorrent.com> Reviewed-by: Anup Patel <anup@brainfault.org>
…tection
The location of the RNMI/E trap vectors in the Smrnmi extension is
implementation-defined, so platforms with vendor-specific NMI vector
mechanisms must install the firmware's NMI entry points themselves.
Add an smrnmi_handlers_init() callback to sbi_platform_operations that
receives the firmware entry points and lets platform code install them
at the hardware-specific vector locations. Two pointers are passed:
- _trap_rnmi_handler: the dedicated RNMI entry point that saves
context using the Smrnmi MN* CSRs and returns via mnret.
- _trap_handler: the regular M-mode trap entry since RNME is taken
as a regular M-mode trap with NMIE=0.
When Smrnmi is present, install the platform's NMI vectors via the new
callback, initialize MNSCRATCH with the per-hart scratch pointer, and
set MNSTATUS.NMIE.
Smrnmi-enabled platforms must register smrnmi_handlers_init; if the
extension is detected but no callback is registered, sbi_panic() is
called since enabling NMIs without handlers in place would route
subsequent traps into nowhere.
Signed-off-by: Evgeny Voevodin <evvoevod@tenstorrent.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Add the xuantie platform callbacks required by the common Smrnmi (Resumable NMI) infrastructure: smrnmi_handlers_init to program the hardware NMI vector, and rnmi_handler to process the NMI when it fires. xuantie vectors RNMI through a single indirectly-accessed rnmi_addr_base register (selected via the miselect/mireg CSR indirect window). NMI is vectored to rnmi_addr_base and double-trap to rnmi_addr_base + 2K, which requires the RNMI asm entry to be 4K-aligned with the double-trap entry 2K above it. That asm layout is not in place yet, so smrnmi_handlers_init is left as a TODO placeholder documenting the intended programming; the NMI source handling in rnmi_handler is likewise a placeholder. The callbacks are registered into generic_platform_ops when the QUIRK_XUANTIE_RNMI quirk is present, matched via the "xuantie,rnmi" compatible. Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
xuantie vectors RNMI through rnmi_addr_base (low 12 bits hardwired to 0) and derives the double-trap (RNME) entry from base + 2K. Align _trap_rnmi_handler to 4K and place a dedicated _trap_rnme_handler exactly 2K above it, so a platform can program rnmi_addr_base with the RNMI base and have both vectors land on the correct entries. _trap_rnme_handler reuses the generic trap handler since RNME is taken as a regular M-mode trap with NMIE=0. sbi_hart.c now passes it as the RNME handler to smrnmi_handlers_init. The rnmi_addr_base programming itself is still a TODO in xuantie_smrnmi_handlers_init; the layout-validation prints added earlier confirm this arrangement (RNMI at a 4K base, RNME at base + 2K). Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
No description provided.