RISC-V Secondary-Hart Startup: Treat SBI HSM Success as an Asynchronous Transition
A supervisor starts a secondary RISC-V hart through SBI, receives success and immediately sends it work. The new hart has not yet initialized its stack or published that its runtime is ready. The mistake is treating acceptance of an asynchronous start request as an application-level rendezvous.
SBI Hart State Management defines both the transition and the entry register contract. Use those guarantees to build the secondary entry path, then add the runtime's own readiness protocol.
Success can precede entry into supervisor code
The ratified SBI v3.0 HSM specification states that sbi_hart_start is asynchronous. It may return before the target begins executing, provided the implementation can ensure the return result is accurate.
The state model includes STOPPED, START_PENDING and STARTED. A successful request establishes that a previously stopped hart will start at the requested address. It does not establish that a task queue, interrupt handler or scheduler on that hart is ready.
Polling sbi_hart_get_status is useful for observing the firmware state, but its result is a snapshot that can change concurrently. It also does not describe how far the newly entered supervisor has progressed through its own initialization.
Enter through a physical-address bootstrap
The start address is a physical address. The target enters S-mode with satp=0 and sstatus.SIE=0, receives its hart ID in a0 and the caller's opaque value in a1. All other registers are unspecified by this interface.
A high virtual entry address that works after the primary hart enables translation is therefore not automatically a valid secondary entry. Provide a bootstrap that can execute under the specified initial mapping state and establish the intended address space deliberately.
The unspecified registers include the stack pointer. Do not enter an ordinary C function that assumes a valid stack before startup has installed one. If opaque encodes a pointer, ensure that the initial entry can interpret it under its current addressing regime; the SBI treats it as an XLEN-bit value, not a magically translated pointer.
Follow the implementation's transition boundary
The OpenSBI v1.9 HSM implementation validates the target and permitted start address, stores next-stage arguments in the target scratch state and transitions from STOPPED to START_PENDING before initiating the platform start or IPI path.
Its finish path changes START_PENDING to STARTED before switching privilege and entering the next stage. This directly illustrates why even observing STARTED cannot prove that the supervisor's entry routine has initialized its own data structures.
The implementation also rejects conflicting state transitions. Do not respond to a slow secondary by repeatedly issuing start requests and treating every non-success result as evidence that the hart is dead. Distinguish an invalid target, invalid executable address, already-started state and implementation failure.
Publish readiness after establishing the runtime contract
The secondary bootstrap should preserve the supplied identity and opaque value as needed, establish its private stack and runtime state, install the intended trap handling and then publish a readiness indication through the system's supported synchronization mechanism.
The primary should dispatch work only after that application-defined indication is observed with the required memory ordering. Define what readiness means: for example, the queue is initialized and the receiving handler can safely consume work. A marker at the first instruction answers a different question.
Use a bounded startup policy with a recoverable failure path. On timeout, retain the request result, last observed HSM state and last bootstrap checkpoint rather than overwriting the evidence with repeated starts. These are proposed integration checks; no secondary hart was started or stopped for this article.
