STATE-CURRENT: execution backend hazard-gated after freeze root-cause; bring-up snapshot refreshed

1 files changed, 22 insertions, 19 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 634088c..b5db841 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-09-30 23:55.** This is a dated public status page, not live
+> **Snapshot: 2026-09-30 23:52.** This is a dated public status page, not live
 > state; it is refreshed on every progress check. Live working notes are
 > maintained outside this repository; the public known-knowns/unknowns document
 > is authoritative here:
@@ -31,7 +31,7 @@ meant to execute on the physical GPU.
 | `cuCtxCreate` returns | ✅ (the whole smoke test now completes) |
 | `cuMemAlloc` + `cuMemcpy` roundtrip (`ALL OK` in the smoke test) | ✅ payload roundtrip verified 64/64 in the guest |
 | Full `nvidia-smi` output / kernel launch | 🟡 the static runtime now initializes end-to-end with **real releases** (`cudaGetDeviceCount`/`cudaSetDevice`/3×`cudaMalloc`/2×`cudaMemcpyHtoD`/`kernel launch`/`cudaGetLastError` all `rc=0`) and queues a kernel launch; execution awaits the backend |
-| CUDA kernel execution (`vectorAdd`) | 🟡 execution-backend bring-up started: the module claims the physical GPU reversibly, stages the matching GSP firmware, and computed the protected-region boot layout; the real GSP boot is the next stage |
+| CUDA kernel execution (`vectorAdd`) | 🟡 execution backend: the device-claim stages (ownership, firmware staging, protected-region boot layout) were verified, but unbinding the distribution driver turns out to hard-freeze this host (dGPU power-gate); the claim path is gate-locked and the backend must be redesigned to keep the distribution driver bound |
 | Graphics (3D), video | ❌ |
 | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
 
@@ -86,12 +86,13 @@ chain succeeds.
   ONE_INC/END_PB headers).
 - Active work: the owed driver-API smoke-test rerun is now **verified 64/64
   (`ALL OK`)** on the current commits, so the recent pump/parser changes did
-  not regress the baseline. Next: the execution backend (decode the queued
-  compute-channel pushes into real submissions on the physical GPU; then the
-  synchronize/DtoH verify). The host is headless, so a controlled
-  device-ownership bring-up is feasible; a step-by-step bring-up ladder
-  (reversible unbind, firmware load, GSP boot, RM client, submission, verify)
-  is drafted.
+  not regress the baseline. The device-claim bring-up verified ownership,
+  firmware staging and the boot layout, but unbinding the distribution driver
+  can power-gate this laptop's dGPU and hard-freeze the host (two occurrences,
+  now root-caused), so that path is disabled behind a two-parameter hazard
+  gate and the execution backend needs a redesign that keeps the distribution
+  driver bound. Meanwhile the emulation/VM CUDA verification cycles resume -
+  they never touch the driver binding.
 - Observability: a size-keyed copy watch, a VRAM shadow dump/search, and an
   operation log are now module parameters, and the test's output survives
   guest-agent stalls via the serial console.
@@ -101,18 +102,20 @@ chain succeeds.
   crashed the guest kernel (a NULL callback in interrupt context) before any
   emulation channel existed - guest-side and untriaged; treat no-watcher runs
   as a known risk. The host stays stable throughout.
-- Execution backend (chosen; bring-up started): the module owns the physical
+- Execution backend (chosen, then hazard-gated): the module owns the physical
   GPU and will run its real GSP firmware as the resource-manager server, so
   real work executes with an unmodified host driver and no host daemon; see
   [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md).
-  First bring-up steps verified live: a default-off claim path releases the
-  distribution driver from the device, binds the module, maps the BARs and
-  samples the falcon state, then releases and rebinds the distribution driver
-  (host driver still healthy); with the device owned, the matching GSP image is
-  fetched and validated (ELF64 RISC-V, loadable image/version/signature
-  sections identified) and the protected-region video-memory/boot layout is
-  computed and logged - all without device writes. The real boot (protected
-  region, secure verification, booter, RISC-V start) is the next stage.
+  The ownership path was verified live (release the distribution driver from
+  the device, bind the module, map the BARs, sample the falcon state, then
+  release and rebind the distribution driver); with the device owned, the
+  matching GSP image is fetched and validated (ELF64 RISC-V, loadable
+  image/version/signature sections identified) and the protected-region
+  video-memory/boot layout is computed and logged - all without device writes.
+  The real GSP boot is **on hold**: the unbind/rebind that device ownership
+  requires can power-gate this laptop's dGPU and hard-freeze the host, so the
+  backend is being redesigned to keep the distribution driver bound
+  (proxy/callback options) before any further boot work.
 - Host stability: the host hang class observed on 2026-09-28 (kernel stack
   overflow in a channel snapshot path) is fixed and frame-audited; repeated
   VM load/attach/teardown cycles run without panics or pstore records. A
@@ -126,8 +129,8 @@ chain succeeds.
   unless both `gsp_phys_gpu=1` and `gsp_phys_hazard_ack=1` are passed;
   normal module/VM work does not touch the driver binding and is unaffected.
   Ownership-changing bring-up must not continue until the execution backend
-  is redesigned to keep the distribution driver bound (host-RM proxy), see
-  the handoff.
+  is redesigned to keep the distribution driver bound (host-RM proxy); see
+  [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md).
 
 ## Initialization, work and teardown path