diff options
| -rw-r--r-- | STATE-CURRENT.md | 19 |
1 files changed, 15 insertions, 4 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index e118627..85fb904 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-10-01 10:40.** This is a dated public status page, not live +> **Snapshot: 2026-10-01 11:30.** 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: physical ownership + firmware staging verified; the unbind/rebind freeze hazard is mitigated by the supervised D0 power-domain lock (3/3 green claim cycles), and the real FB size (8 GiB) and boot layout are verified live. The supervised live secure-verification run raised the protected region (WPR2 up) for the first time, then proved a secure-verification-only carve is not host-recoverable on this fused part, so the fail-safe held the device and an approved reboot restored it (distribution driver rebound, GPU healthy). That one-way stage is now retired: the only device-write path is a single full boot lifecycle (secure verification -> bootloader -> RISC-V start -> resource-manager initialization), whose code is implemented in the module sources and has now run live: the first real boot raised WPR2, passed Booter Load and went RISC-V active, and the module received the first real GSP-RM message (event 0x1002); init-done (0x1001) and a clean release are the next steps (see the 2026-10-01 section). | +| CUDA kernel execution (`vectorAdd`) | 🟡 execution backend: physical ownership + firmware staging verified; the unbind/rebind freeze hazard is mitigated by the supervised D0 power-domain lock (3/3 green claim cycles), and the real FB size (8 GiB) and boot layout are verified live. The supervised live secure-verification run raised the protected region (WPR2 up) for the first time, then proved a secure-verification-only carve is not host-recoverable on this fused part, so the fail-safe held the device and an approved reboot restored it (distribution driver rebound, GPU healthy). That one-way stage is now retired: the only device-write path is a single full boot lifecycle (secure verification -> bootloader -> RISC-V start -> resource-manager initialization), whose code is implemented in the module sources and has now run live: the first real boot raised WPR2, passed Booter Load and went RISC-V active, and the module received the first real GSP-RM message (event 0x1002); init-done (0x1001) and a clean release are the next steps (see the 2026-10-01 section). A second live boot on 2026-10-01 proved the full boot sequence again (protected region up, bootloader halt, RISC-V active, first GSP-RM message) and reached the resource-manager's inline CPU-sequencer request; the host executor rejected the real request because of an over-strict internal size cap, which was found with a raw read of the message in host memory, fixed, and rebuilt. The next supervised cycle is expected to run the sequencer, receive init-done and complete a clean release via the shutdown RPC. | | Graphics (3D), video | ❌ | | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ | @@ -61,7 +61,12 @@ chain succeeds. initialization). That lifecycle is now implemented in the module sources (bootloader runner + generated verification/boot image data) and has run live under the supervised harness: the first real boot succeeded (see the - section below). + section below), and a second live cycle on the rung-4 build repeated the + boot and reached the server's run-sequencer request; the executor's size + cap rejected the real request value (16354), which was diagnosed from a + raw host-memory read of the message, fixed, and rebuilt; the claimed + session from that cycle is awaiting a supervised power cycle to run the + corrected boot+shutdown flow. - **The full CUDA driver-API smoke test passes with correct data**: the client completes `cuCtxCreate -> cuMemAlloc -> cuMemcpyHtoD -> cuMemcpyDtoH -> cuMemFree -> cuCtxDestroy` and prints `ALL OK`, with the 64-byte payload @@ -233,7 +238,13 @@ approval, because the current claimed session cannot be released); the rung `f61308bd…`; the cycle should run `phys_claim_cycle.sh --yes --hold 60 --cycles 1 --boot --keep`, then exercise `gsp-phys-rm-probe` (static-info round trip) and `gsp-phys-unload-rpc` (server shutdown) through the module's -read-only/debug state files before a clean `rmmod`. +read-only/debug state files before a clean `rmmod`. That cycle has now run: +the boot repeated green, and the server's run-sequencer request was received +but rejected by an over-strict host-side cap on the request's own buffer size. +The message was read raw from host memory, the cap corrected and the module +rebuilt; because the claimed session cannot be released without the shutdown +RPC, the next supervised power cycle will run the corrected boot-and-shutdown +flow. Ending the claimed session (harness notice): `sudo rmmod open_iov_vfio`, then `echo auto | sudo tee /sys/bus/pci/devices/0000:01:00.0/power/control` and the |