From 066953e10c1305463d4e80933834cf26b984bbfc Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Thu, 1 Oct 2026 00:12:40 -0400 Subject: STATE-CURRENT: power-domain lock implemented behind the hazard gate; snapshot refreshed --- STATE-CURRENT.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) (limited to 'STATE-CURRENT.md') diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 1cd6620..d57a7f4 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-09-30 23:52.** This is a dated public status page, not live +> **Snapshot: 2026-10-01 00:12.** 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: @@ -94,8 +94,9 @@ 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 and the execution backend needs a redesign that keeps the distribution - driver bound. Meanwhile the emulation/VM CUDA verification cycles resume - + 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. - 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 @@ -132,11 +133,13 @@ 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 it must not run again until the - designed power-domain lock (hold the GPU and its board functions plus the - root port in D0 across the handoff, aborting on any power-loss signature) - is implemented and verified under supervision; normal module/VM work does - not touch the driver binding and is unaffected. See + `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, + 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 [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md). ## Initialization, work and teardown path -- cgit v1.2.3