diff options
Diffstat (limited to 'STATE-CURRENT.md')
| -rw-r--r-- | STATE-CURRENT.md | 40 |
1 files changed, 23 insertions, 17 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index d57a7f4..3a3fd3d 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -94,10 +94,13 @@ chain succeeds. 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; a power-domain lock that keeps the board in D0 across the handoff is - now implemented behind that gate and awaits a supervised claim/release test. - Meanwhile the emulation/VM CUDA verification cycles resume - - they never touch the driver binding. + gate. A power-domain lock that keeps the board in D0 across the handoff is + implemented and **verified across three supervised claim/release cycles on + 2026-10-01** (zero power-domain cycles, zero failed resumes, distribution + driver rebound cleanly each time, host healthy); the verified launch + harness holds the GPU and root port in D0 before the distribution driver is + stopped, and the root-port hold is the load-bearing invariant. The real GSP + boot is the next stage. - 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. @@ -107,9 +110,10 @@ 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, 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 +- Execution backend (chosen; ownership hazard mitigated and verified): 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). The ownership path was verified live (release the distribution driver from the device, bind the module, map the BARs, sample the falcon state, then @@ -117,10 +121,9 @@ chain succeeds. 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. + The unbind/rebind hazard is mitigated by the D0 power-domain lock, verified + over three supervised cycles; the next stage is the real GSP boot (secure + verification, booter, RISC-V start, resource-manager init). - 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 @@ -133,13 +136,16 @@ chain succeeds. about a minute later (no crash record; journal stops, pstore empty; both occurrences followed an unbind/rebind, and prior log history has no other instance). The claim path refuses to run unless both `gsp_phys_gpu=1` and - `gsp_phys_hazard_ack=1` are passed, and the designed power-domain lock (hold - the GPU and its board functions plus the root port in D0 across the handoff, + `gsp_phys_hazard_ack=1` are passed, and the power-domain lock (hold the GPU + and its board functions plus the root port in D0 across the handoff, aborting and holding the locks on any power-loss signature) is now - **implemented** behind that gate; it must still pass a supervised - claim/release test before any further backend boot work, and it must not run - unattended. Normal module/VM work does not touch the driver binding and is - unaffected. See + **implemented and verified across three supervised claim/release cycles** + (2026-10-01: zero power-domain cycles, zero failed resumes, clean rebind, + 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 [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md). ## Initialization, work and teardown path |