vms-feb: executive-resident async AST delivery — $HIBER interrupted by a queued AST (cross-process)

[baron-3dl]

What

Real VMS asynchronous AST delivery semantics: a queued AST is now delivered asynchronously to a hibernating process, interrupting $HIBER, instead of only draining on an explicit sys$setast(1). This is the keystone prereq for MMK's exec-drive (spine #4, vms-b23) — tests/corpus/tier3-mmk/build_target.c uses exactly sys$wake(0,0) + sys$hiber().

The gap (found by vms-b23 #454): the AST queue existed but there was no async delivery — sys$hiber was a bare pause(), so a process that armed a write-attention AST on a mailbox and $HIBERed waiting for it was never woken when another process wrote → deadlock.

Mechanism

Split the wait (executive) from the dispatch (userspace — the AST routine address is only valid in the target process). Executive-resident, cross-process, through /dev/vms (Rule 9 / INV-6 — no per-process fake):

• VMS_IOCTL_HIBER blocks until a $WAKE is pending or an AST is deliverable at/below the caller's mode (vms_ast_has_deliverable, same bound as DELIVERAST); returns woken=1 iff a $WAKE released it (consuming a sticky wake_pending bit), 0 iff an AST did.
• VMS_IOCTL_WAKE sets the sticky wake bit on the target (self when vms_pid==0 — the MMK self-wake; else a VMS PID gated by GROUP/WORLD) and wakes it. Replaces the old raw-linux-pid SIGCONT shim.
• vms_ast_notify_arrival — every AST-enqueue path ($DCLAST, mailbox write-attention in vms_mbx.c, lock completion/blocking ASTs in vms_lock.c) broadcasts the target's hiber_wq after queuing, under hiber_lock → lost-wakeup-free, no lock-order inversion.
• sys$hiber loops vms_kif_hiber() + vms$$deliver_pending_asts(), returning only on a $WAKE (its own, or one an AST issued) — VMS re-hibernates after an AST that does not $WAKE. sys$wake now targets a VMS PID (self when NULL).

New universals vms_kif_hiber/vms_kif_wake appended to the frozen symbol vector (append-only). Clean-room provenance + full design: docs/design-async-ast-delivery-ovmx.md (VSI System Services $HIBER/$WAKE + Programming Concepts AST semantics; OVMX choices labelled, Rule 8).

Proof (real /dev/vms, QEMU — booted locally)

tests/qemu/test_syssvc_hiber_ast.c: process A arms a write-attention AST (routine self-$WAKEs) and sys$hibers with no explicit $SETAST drain; unrelated re-exec'd process B assigns the mailbox by name and writes it; asserts A's $HIBER returns and the AST ran — a bounded coordinator wait, so a deadlock is a named FAIL, not a QEMU-wide hang. Second scenario proves sticky wake ($WAKE before $HIBER returns immediately).

• test_syssvc_hiber_ast: 5 passed, 0 failed against a real insmod'd vms.ko.
• Full harness: 73 suites passed, 0 failed — no regression in test_kmod_ast / test_kmod_lock_mproc / test_kmod_eflag_mproc / test_syssvc_ast / test_syssvc_ast_secmode / test_syssvc_mbx_wrtattn / test_syssvc_mbx_cmdresp.
• Honest-skip: returns 77 with no /dev/vms (CI negative-control contract).
• Negative control hiber-ast-not-delivered (floor 93→94): removes the arrival broadcast → the AST is queued but $HIBER never wakes → deadlock → this suite reddens, while test_syssvc_mbx_wrtattn (explicit $SETAST, never hibers) stays green. Mutation verified unique + idempotent; the CI per-facility negctl shard exercises it against real /dev/vms.

Scope / deferred

• Self-directed $WAKE and single-node $WAKE-by-VMS-PID implemented (self-wake proven). $WAKE by process name (prcnam) not resolved — redirected to self, same limitation the other prcnam-taking process services carry.
• Upward access-mode preemption (a kernel-mode AST trapping a user-mode process) is not introduced — remains the labelled OVMX containment choice already in vms_ast.c. vms-feb adds when a deliverable AST wakes a hibernating process, not a new preemption model.
• Unblocks MMK's send_cmd_and_wait at the AST/$HIBER layer; IO$M_NOW (vms-5df) and DCL-mailbox wiring (vms-786) are still needed for the full MMK drive.

🤖 Generated with Claude Code