diff options
| -rw-r--r-- | STATE-CURRENT.md | 37 |
1 files changed, 19 insertions, 18 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index ee6cb5a..61f10f0 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-09-30 20:15.** This is a dated public status page, not live +> **Snapshot: 2026-09-30 22:45.** 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: @@ -84,27 +84,27 @@ chain succeeds. both fixed, and the runtime init completes in ~1 min with real releases. The content rescue also learned the real method encoding (NON_INC/IMMD/ ONE_INC/END_PB headers). -- Active work: (1) rerun the driver-API smoke test (cdt2) on the current - module to confirm no regression, and confirm the two known gaps (GMMU walks - for runtime VAs, staging-VA resolution) are non-blocking; (2) 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. - Work resumed with no-watcher, real-release runtime cycles: a new commit - delivers the UVM tracking releases without host-side pins, and one - real-release, no-watcher run has reached `cudaGetDeviceCount` success; the - cycles continue with a fresh module each time. +- 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. - 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. - Guest health note: agent/SSH timeouts during long runs are the guest-side trace reader flooding the ring; they recover on their own, so a first - timeout is not a reason to restart the VM. A guest kernel fault appeared in - the serial log during the latest cycle (guest-side; host stable) and is - under investigation. -- Execution backend (chosen, not started): the module will own the physical - GPU and run its real GSP firmware as the resource-manager server, so real - work executes with an unmodified host driver and no host daemon; see + timeout is not a reason to restart the VM. Separately, one no-watcher boot + 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 ladder drafted, not started): the + module will own the physical GPU and 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). - 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 @@ -191,7 +191,8 @@ Recent chain of walls removed (2026-09-28 to 2026-09-30): -> GMMU walk decode fixed (child/leaf encoding) -> inline HtoD lands -> DtoH copy-engine-on-compute allowed -> payload roundtrip 64/64 -> runtime client initializes rc=0 (legacy clock-domain fix) -> kernel launch - queued -> execution backend is the next wall + queued -> real-release chain rc=0 (pump bookkeeping fixes) -> execution + backend bring-up is the next wall ``` ## Tools, code paths and fixes behind this progress |