diff options
Diffstat (limited to 'STATE-CURRENT.md')
| -rw-r--r-- | STATE-CURRENT.md | 41 |
1 files changed, 22 insertions, 19 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 634088c..b5db841 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-09-30 23:55.** This is a dated public status page, not live +> **Snapshot: 2026-09-30 23:52.** 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 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 | +| CUDA kernel execution (`vectorAdd`) | 🟡 execution backend: the device-claim stages (ownership, firmware staging, protected-region boot layout) were verified, but unbinding the distribution driver turns out to hard-freeze this host (dGPU power-gate); the claim path is gate-locked and the backend must be redesigned to keep the distribution driver bound | | Graphics (3D), video | ❌ | | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ | @@ -86,12 +86,13 @@ chain succeeds. ONE_INC/END_PB headers). - Active work: the owed driver-API smoke-test rerun is now **verified 64/64 (`ALL OK`)** on the current commits, so the recent pump/parser changes did - not regress the baseline. Next: the execution backend (decode the queued - compute-channel pushes into real submissions on the physical GPU; then the - synchronize/DtoH verify). The host is headless, so a controlled - device-ownership bring-up is feasible; a step-by-step bring-up ladder - (reversible unbind, firmware load, GSP boot, RM client, submission, verify) - is drafted. + not regress the baseline. The device-claim bring-up verified ownership, + firmware staging and the boot layout, but unbinding the distribution driver + can power-gate this laptop's dGPU and hard-freeze the host (two occurrences, + now root-caused), so that path is disabled behind a two-parameter hazard + gate and the execution backend needs a redesign that keeps the distribution + driver bound. Meanwhile the emulation/VM CUDA verification cycles resume - + they never touch the driver binding. - Observability: a size-keyed copy watch, a VRAM shadow dump/search, and an operation log are now module parameters, and the test's output survives guest-agent stalls via the serial console. @@ -101,18 +102,20 @@ chain succeeds. crashed the guest kernel (a NULL callback in interrupt context) before any emulation channel existed - guest-side and untriaged; treat no-watcher runs as a known risk. The host stays stable throughout. -- Execution backend (chosen; bring-up started): the module owns the physical +- Execution backend (chosen, then hazard-gated): the module owns the physical GPU and will run its real GSP firmware as the resource-manager server, so real work executes with an unmodified host driver and no host daemon; see [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md). - First bring-up steps verified live: a default-off claim path releases the - distribution driver from the device, binds the module, maps the BARs and - 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 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. + The ownership path was verified live (release the distribution driver from + the device, bind the module, map the BARs, sample the falcon state, then + release and rebind the distribution driver); with the device owned, the + matching GSP image is fetched and validated (ELF64 RISC-V, loadable + image/version/signature sections identified) and the protected-region + video-memory/boot layout is computed and logged - all without device writes. + The real GSP boot is **on hold**: the unbind/rebind that device ownership + requires can power-gate this laptop's dGPU and hard-freeze the host, so the + backend is being redesigned to keep the distribution driver bound + (proxy/callback options) before any further boot work. - 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 @@ -126,8 +129,8 @@ chain succeeds. unless both `gsp_phys_gpu=1` and `gsp_phys_hazard_ack=1` are passed; normal module/VM work does not touch the driver binding and is unaffected. Ownership-changing bring-up must not continue until the execution backend - is redesigned to keep the distribution driver bound (host-RM proxy), see - the handoff. + is redesigned to keep the distribution driver bound (host-RM proxy); see + [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md). ## Initialization, work and teardown path |