diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-30 23:44:55 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-30 23:44:55 -0400 |
| commit | 770e61ae3b7c85bd0d19ff2301f00acbab50d382 (patch) | |
| tree | 2894cba58868163c2025825bee6d889f0948f62e /STATE-CURRENT.md | |
| parent | fd8c35f9d3349ae58c0a0cf570a4ab154bf375e9 (diff) | |
| download | open-iov-770e61ae3b7c85bd0d19ff2301f00acbab50d382.tar.gz open-iov-770e61ae3b7c85bd0d19ff2301f00acbab50d382.zip | |
STATE-CURRENT: execution-backend bring-up started (claim + GSP firmware verified); freeze-class watch note
Diffstat (limited to 'STATE-CURRENT.md')
| -rw-r--r-- | STATE-CURRENT.md | 15 |
1 files changed, 11 insertions, 4 deletions
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 |