User:Gravaera/RISC-V Trap Architecture

Trap architecture: Trap is the umbrella term for IRQs, exceptions etc. Vertical traps are those taken from lower to higher. Horizontal traps are those taken from same to same. By default, all traps at any privlvl are taken directly to MACHINE mode.

• xRET (MRET, SRET, URET) are used to return from mode X respectively.
• RISC-V supports the idea of userlvl traps -- traps taken from highpriv to userlvl.

* When a trap occurs, CPU stores Previous Privlvl in xPP bit (xSTATUS.[xPP]). ^ You can also read yPP from mode X where Y is a lower privlvl. * When a trap occurs from priv Y to X: * xPP <= y; xPIE <= xIE. xIE <= 0. * When executing xRET (returning from from X to Y): * xIE <= xPIE; [MODECHANGE]; xPIE = 1 ALWAYS; xPP = U (or M if U unsupp) ALWAYS; * OS is expected to manually save xSTATUS. * MISA.Extensions[N]: Indicates support for user-level traps.

Trap sequence: On trap taken to mode X: * xCause <= exception cause; * xEPC <= PC that triggered the trap. * Then the standard trap sequence goes with xIE, xPIE, xPP [out of order]. * If the trap was delegated, the MCAUSE, MEPC, MIE, MPIE, MPP regs are not changed.

• Delegation is based on the prilvl the trap was taken from. So a trap taken from MMode cannot be

 delegated to SMode. It must have been taken FROM UMode or SMode to be delegated BY MMode TO SMode.
 ^ See MEDELEG and MIDELEG CSRs for trap delegation information.

Interrupt architecture:

• RISC-V specifies the following events as "interrupts":

 * Timer Interrupt (xTI?): mip.[MTIP]: cleared by writing to timer compare reg.
   ^ MMode can only trigger a MTimer event by writing to the timer CSRs.

* MMode can trigger a STimer or UTimer event by writing to mip[STIP] or mip.[UTIP]. ^ SMode and UMode must clear the STIP/UTIP bit by making calls to AEE/SEE through ABI/SBI.

 ^ Software Interrupt (mip.[xSI?]):
   ^ These are also the vector for IPIs.
 ^ External Interrupt (mip.[xEI?])

xSTATUS.[xIE]: 0=IRQs disabled; 1=IRQs enabled for respective mode. * While in mode X, IRQs in mode X-1 and lower are always disabled. * While in mode X, IRQs in mode X+1 and higher ALWAYS ENabled. Highpriv IRQs always taken.

IRQ PRIORITY: Harts prioritize these three types of interrupts as follows: External IRQ > Software Interrupt > Timer Interrupt > Synchronous traps (exceptions?). ^ It is a bit odd that they prioritize Softint over timer, but that may be a symptom of IPIs being delivered as Software Ints.

An IRQ will be taken if its bit is set in both mie.[CAUSE] and if mip.[CAUSE] gets set.

IPIs: * IPIs are simulated as software interrupts. * The source hart writes to the target hart's mip.[MSIP] CSR, and this delivers the IPI. ^ SMode must deliver IPIs by executing calls to the SEE. ^ SMode CLEARS pending IPIs/SoftInts by clearing sip.[SSIP]. ^ UMode delivers IPIs (if it ever has to) by calling the AEE. * A hart can IPI itself by writing to its own mip.[MSIP]. * The mechanism for writing to a foreign hart's CSR space is IMPLEMENTATION DEFINED. ^ Might be via MMIO or some other mechanism.

External IRQs: * mip.[MEIP] is set by an external IRQ signal. Cleared by writing to the platform's PIC. * mip.[S/U-EIP] work the same way.

Injecting external IRQs into SMode/UMode: * See Virtualization section.

Non-Maskable IRQ: * There is no Interrupt Pending bit in mip for an NMI-EIP because a pending NMI can be recognized implicitly by the very fact that you are executing the NMI handler.