"Zawrs": Wait-on-Reservation-Set

Part III Linux boot: optional Vol. I (Unprivileged) pp. 74–75 · ~3 min read

PAUSE throttles a spin loop; Zawrs parks it. The idiom turns the cache-coherence protocol into a doorbell: take an LR on the watched location to register a reservation set, then WRS stalls the hart in low power until something invalidates that reservation — i.e., until the store you were polling for actually happens.

funct123120000001915000141200000117111001160WRS.NTO / WRS.STO (SYSTEM)
Click a field for its role.
# consumer waiting on queue tail (futex-style, any privilege mode)
retry:
    lr.d    t0, (a0)          # register reservation on the flag
    bnez    t0, ready         # already set? done
    wrs.nto                   # sleep until a store hits the line,
    j       retry             #   an interrupt pends, or spuriously
ready:

The stall persists only while all hold: the reservation set is valid, no interrupt is pending (even a globally-disabled one — the WFI observation rule), and, for STO, the short timeout (guidance: 10–100× a cache-miss latency) hasn’t lapsed. Implementations may end the stall spuriously at any time — the loop is mandatory.

The three wait instructions compared
Wait boundTrap rules
WRS.NTONone (reservation/interrupt only)mstatus.TW=1 below M + no completion in bounded time → illegal-instruction; hstatus.VTW (TW=0) in VS/VU → virtual-instruction. U-mode with TW=0: expressly LEGAL.
WRS.STOImplementation-defined short timeoutNever traps under TW/VTW — the timeout already bounds the hypervisor’s exposure.
WFI (ch. II·3)Until interruptTW/VTW trap after bounded wait; commonly illegal in U-mode outright.
Dotted-underlined cells have explanations — click one.

Hardware Designer Notes

The one invariant to guard in RTL: the snoop logic that invalidates the reservation must stay powered while the core sleeps, or wakeups get lost and the NOP-fallback is the only correct choice. Linux uses Zawrs for qspinlock/futex waits when advertised.

Minimal Linux-boot hart MUST

  • Wire reservation-set invalidation (the snoop you already have for SC failure) and the pending-interrupt signal (even-if-disabled variant) as stall-exit conditions
  • Honor WFI’s resume rules and the TW/VTW trap matrix for WRS.NTO

MAY simplify / trap-and-emulate

  • Implement both as NOPs — a hart that never stalls satisfies every rule (spurious completion is always legal)
  • Pick any STO timeout in the guidance band; a simple counter suffices
  • Gate into a real low-power state (clock-gate the core, keep the snoop path alive) — the intended payoff

Check yourself — Zawrs

1.How does the LR + WRS.NTO idiom eliminate the spin loop's energy cost?

2.Why can WRS.NTO trap under mstatus.TW but WRS.STO never does?

3.Roughly how long should WRS.STO's timeout be, and what must software assume about wakeups?

3 questions