STATE-CURRENT: recovery complete (approved reboot restored GPU); secure-verification-only retired; full boot lifecycle next

1 files changed, 15 insertions, 11 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 131cf6e..6771f53 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-10-01 08:12.** This is a dated public status page, not live
+> **Snapshot: 2026-10-01 09:12.** 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: physical ownership + firmware staging verified; the unbind/rebind freeze hazard is mitigated by the supervised D0 power-domain lock (3/3 green claim cycles), and the real FB size (8 GiB) and boot layout are verified live. The supervised live secure-verification run has now raised the protected region (WPR2 up) for the first time, but its release teardown could not clear WPR2, so the fail-safe held the device (distribution driver unbound, power-domain locks held) pending a rescue; the booter/RISC-V/RM-init stages follow. |
+| CUDA kernel execution (`vectorAdd`) | 🟡 execution backend: physical ownership + firmware staging verified; the unbind/rebind freeze hazard is mitigated by the supervised D0 power-domain lock (3/3 green claim cycles), and the real FB size (8 GiB) and boot layout are verified live. The supervised live secure-verification run raised the protected region (WPR2 up) for the first time, then proved a secure-verification-only carve is not host-recoverable on this fused part, so the fail-safe held the device and an approved reboot restored it (distribution driver rebound, GPU healthy). That one-way stage is now retired: the only device-write path is a single full boot lifecycle (secure verification -> bootloader -> RISC-V start -> resource-manager initialization), which is being implemented. |
 | Graphics (3D), video | ❌ |
 | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
 
@@ -51,11 +51,15 @@ chain succeeds.
   reached the first successful secure-verification (FWSEC) carve of the
   protected region on the real TU104 under the verified D0 power-domain
   harness. The teardown of a FWSEC-only carve is not host-recoverable on this
-  fused part, so the GPU is left in the documented fail-safe (protected
-  region up, distribution driver deliberately not rebound) and is being
-  restored by an approved reboot; the next stage is a single-cycle real boot
-  (secure verification -> bootloader -> RISC-V start -> resource-manager
-  initialization) so the normal boot lifecycle makes teardown valid.
+  fused part (both the secure-scratch and MMU privilege masks are fuse-locked,
+  so the bootloader handoff cannot be seeded and WPR2 cannot be unlocked from
+  the host), so the fail-safe deliberately held the device and an **approved
+  reboot restored it** (distribution driver rebound, `nvidia-smi -L` green,
+  host healthy, no crash record). The one-way stage is now retired: the only
+  device-write path is a single supervised full boot lifecycle (secure
+  verification -> bootloader -> RISC-V start -> resource-manager
+  initialization), whose next stage is being implemented so the normal boot
+  lifecycle makes teardown valid.
 - **The full CUDA driver-API smoke test passes with correct data**: the client
   completes `cuCtxCreate -> cuMemAlloc -> cuMemcpyHtoD -> cuMemcpyDtoH ->
   cuMemFree -> cuCtxDestroy` and prints `ALL OK`, with the 64-byte payload
@@ -170,10 +174,10 @@ chain succeeds.
   host healthy). The verified launch harness holds the GPU and root port in
   D0 before the distribution driver is stopped; the root-port hold is the
   load-bearing invariant. The path must still not run unattended and every
-  cycle is supervised. As of the latest run the device sits in the fail-safe
-  state described above (distribution driver unbound, protected region up,
-  locks held) until a supervised rescue or an approved reboot; normal
-  module/VM work does not touch the driver binding and is unaffected. See
+  cycle is supervised. The device has since been restored by the approved
+  reboot (distribution driver rebound, GPU healthy); the secure-verification
+  stage is now folded into a single full boot lifecycle, and normal module/VM
+  work does not touch the driver binding and is unaffected. See
   [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md).
 
 ## Initialization, work and teardown path