From 4805f88b6d1449d23bf8af2e80a9b2b1984f7189 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Thu, 1 Oct 2026 09:13:00 -0400 Subject: STATE-CURRENT: recovery complete (approved reboot restored GPU); secure-verification-only retired; full boot lifecycle next --- STATE-CURRENT.md | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) (limited to 'STATE-CURRENT.md') 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 -- cgit v1.2.3