From 770e61ae3b7c85bd0d19ff2301f00acbab50d382 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Wed, 30 Sep 2026 23:44:55 -0400 Subject: STATE-CURRENT: execution-backend bring-up started (claim + GSP firmware verified); freeze-class watch note --- STATE-CURRENT.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'STATE-CURRENT.md') diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index ed92566..018a8d5 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-09-30 23:45.** This is a dated public status page, not live +> **Snapshot: 2026-09-30 23:55.** 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`) | ❌ not started (forwarding layer absent) | +| 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 | | Graphics (3D), video | ❌ | | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ | @@ -110,11 +110,18 @@ chain succeeds. 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 held for the boot stage. The real boot (protected + 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. - 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. + VM load/attach/teardown cycles run without panics or pstore records. A + second, separate freeze class is under watch: twice the host has become + unresponsive roughly a minute after the distribution driver was unbound and + rebound on the physical GPU (once with a VM attached, once without; no crash + record either time, both needed a hard reboot). The device reset/rebind path + is the common factor; ownership-changing bring-up cycles are being run one + per boot with a watchdog and persistent logging. ## Initialization, work and teardown path -- cgit v1.2.3