RISC-V Interrupt Delegation: Explain a Pending Source That Cannot Trap in the Current Mode

An interrupt is pending and individually enabled, but firmware remains in a polling loop. Setting another global-enable bit does not help. On RISC-V, the missing step can be identifying which privilege mode is allowed to receive that interrupt while the hart is executing its current mode.

This discussion uses ordinary M, S and U modes. Virtualized interrupt delivery and additional interrupt-controller extensions require their own routing rules.

Find the destination before interpreting global enable

The Machine-Level ISA delegation rules distinguish mideleg from medeleg. The former routes supported interrupt causes; the latter concerns synchronous exceptions. Changing an exception-delegation bit cannot repair an interrupt-routing problem.

For a machine-directed interrupt, the relevant pending and individual-enable bits must be set, and its delegation bit must be clear. The global condition is then either execution in M-mode with mstatus.MIE set, or execution below M-mode. In the latter case, MIE is not the switch that masks machine-directed interrupts.

Thus a supervisor's local interrupt-disable operation cannot be assumed to exclude a higher-privilege machine interrupt. That matters when reasoning about a critical section shared with machine firmware: supervisor masking alone is not a cross-privilege exclusion mechanism.

Delegation can make a pending source wait during M-mode

When a supported supervisor interrupt is delegated, it is masked at the delegating privilege level. A delegated supervisor timer interrupt does not trap to M-mode merely because M-mode currently runs with MIE set. It also cannot interrupt M-mode by trapping downward into S-mode.

The Supervisor-Level ISA interrupt predicate requires pending and enabled bits in sip and sie, plus either S-mode execution with sstatus.SIE set or execution below S-mode.

Consider a delegated supervisor timer interrupt that remains pending during a long machine-mode service. Enabling SIE does not make it preempt that machine-mode service. After the firmware returns to a suitable lower mode, delivery can become eligible. This is a privilege-routing explanation, not evidence that the timer lost its deadline.

Read the trap record belonging to the destination

A trap taken into S-mode updates the supervisor trap record, including scause, sepc and stval, with the specified supervisor status transitions. It does not update mcause or mepc as if a machine trap had occurred.

A diagnostic that samples only machine trap CSRs can therefore display an old event while the supervisor has handled the new interrupt. Match the recorded cause, program counter and status to the destination mode before interpreting them.

Delegation is also subject to supported, writable fields. Inspect the actual readback from the initialized configuration. The specification describes probing supported bits, but blindly writing every bit on a running product is not an appropriate diagnostic shortcut; use controlled firmware initialization and the platform's supported policy.

Inspect the policy that firmware actually installed

In OpenSBI v1.9 delegate_traps, the interrupt mask includes supervisor software, timer and external interrupts, plus the supported PMU interrupt mask. Exception delegation is assembled separately, with platform and hypervisor conditions.

Use those actual masks rather than inferring behavior from a nearby comment or a generic description of OpenSBI. Downstream firmware may choose another policy, and a later stage may change the writable state.

For a proposed diagnosis, capture the current execution mode, effective destination, pending bit, individual enable and destination's applicable global condition. Evaluate them as one predicate at the observed point. This establishes whether the source should be delivered now or should wait for a privilege transition. No firmware or interrupt sequence was executed here.