RISC-V Executable Memory: Synchronize Instruction Fetch on Every Executing Hart

A loader copies new instructions into RAM and another hart branches to the new entry point. The bytes look correct through a data read, yet the executing hart can still observe an old instruction stream. Data visibility and instruction-fetch visibility are separate synchronization obligations on RISC-V.

The relevant scope is every hart that may execute the code. A fence performed only by the writer is insufficient when execution occurs elsewhere.

FENCE.I establishes a local instruction-stream boundary

The Zifencei 2.0 specification defines FENCE.I to synchronize prior explicit memory accesses with subsequent instruction fetches on the same hart. It ensures that instruction fetches see prior data stores already visible to that hart.

This is why observing a correct checksum through the data path does not establish that the next instruction fetch uses those bytes. A data-memory publication protocol can transfer knowledge that new code exists without performing the required instruction-stream synchronization.

For a single hart generating and then executing its own code, inspect the path from the final code store to the local instruction fence and the first fetch from the new region. An instruction fence before the last patch or relocation write leaves that later modification outside the intended sequence.

Remote execution requires a remote fetch boundary

For multiple harts, the specification calls for the writing hart to execute a data fence before requesting that remote harts execute FENCE.I. Each executing hart needs its relevant instruction-fetch boundary after the updated stores become visible.

A conceptual publication sequence is: finish writing the instructions, order those stores before the synchronization request, have the intended executors perform their instruction fence, and release them to the new entry point only under the selected synchronization protocol. This is an ordering outline, not a complete portable live-patching algorithm.

In particular, it does not make multi-instruction replacement atomic. Prevent execution through a partially modified region using the platform's supported update design. Instruction visibility cannot replace control over when another hart enters the code.

Use the remote-fence service with an explicit target set

The ratified SBI v3.0 RFENCE extension provides sbi_remote_fence_i with a hart mask and base. Its operation instructs the selected remote harts to execute FENCE.I.

Determine which harts may execute the generated code rather than choosing only the hart that currently runs the receiving task. Check extension availability and the returned error. An invalid target can produce SBI_ERR_INVALID_PARAM; silently ignoring that result does not establish instruction visibility on the omitted executor.

The specification's success table describes successful IPI submission to the targets. A surrounding loader or runtime must still follow its supported handoff and completion contract; do not invent an additional application-level acknowledgement guarantee from a generic success integer alone.

Account for migration and later entrants

The Zifencei discussion explicitly notes that a local fence is insufficient for a user thread that can migrate to another physical hart. Use the operating system's supported instruction-cache synchronization interface rather than treating an inline fence.i as a process-wide operation.

The same coverage problem occurs when a secondary hart is brought online after a local update protocol has finished. Its startup path must establish the required visibility before it enters the affected code, according to the platform's execution environment.

A proposed review labels the writer, code interval, final modification, synchronization request and every possible executor. The acceptance question is whether each executor crosses the appropriate fetch boundary after the new code becomes visible. This does not prove translation correctness, executable-memory permissions or safe concurrent patching; those are separate contracts. No instructions were generated or executed for this article.