diff options
| -rw-r--r-- | STATE-CURRENT.md | 23 |
1 files changed, 14 insertions, 9 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 3a19aa3..ffa2dde 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-10-01 07:12.** This is a dated public status page, not live +> **Snapshot: 2026-10-01 08: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), the real FB size (8 GiB) and boot layout are verified live, and the secure-verification stage is implemented build-only; a read-only dry-run precedes the live GSP boot | +| 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. | | Graphics (3D), video | ❌ | | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ | @@ -133,11 +133,14 @@ chain succeeds. verified live under the supervised claim harness (three green claim/release cycles; the root-port D0 hold is the load-bearing invariant), and the secure-verification stage (VBIOS security-blob extraction, falcon reset and - staging) is implemented build-only; before any live boot the plan now - requires an offline VBIOS analysis and a read-only dry-run of the staging - computation (zero device writes) under the supervised claim harness, - pending adversarial review and explicit approval; the booter and RISC-V - start follow. + staging) was validated offline and in a read-only dry-run, then run **live + under the supervised claim harness**: it raised the protected region (WPR2 + up) for the first time on real hardware. Its release teardown, however, + could not clear WPR2, and the fail-safe deliberately held the device + (distribution driver unbound, power-domain locks held) rather than hand it + back; a rescue path is being debugged (or, failing that, an approved + reboot). A distribution-driver bus-master quirk on the claim path was also + found and fixed in this run. The booter and RISC-V start follow. - 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 @@ -158,8 +161,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. Normal module/VM work does not touch the driver - binding and is unaffected. See + 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 [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md). ## Initialization, work and teardown path |