summaryrefslogtreecommitdiffstats
path: root/STATE-CURRENT.md
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-01 16:48:19 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-01 16:48:19 -0400
commit6076a58e85168b2cdd7efbde2e226708f5c5c5b0 (patch)
treef4a0f5a7fe13d6dcf2272f4ff42f23a3ed01360d /STATE-CURRENT.md
parent0a5a112a5c8204dc20935ae718c5c0346a8d09be (diff)
downloadopen-iov-6076a58e85168b2cdd7efbde2e226708f5c5c5b0.tar.gz
open-iov-6076a58e85168b2cdd7efbde2e226708f5c5c5b0.zip
STATE-CURRENT: 16:47 check-back - ladder row updated for the GSP-RM init milestone (log-ring and identity fixes)
Diffstat (limited to 'STATE-CURRENT.md')
-rw-r--r--STATE-CURRENT.md37
1 files changed, 19 insertions, 18 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 20a0120..be9cd48 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
# Open-IOV Current State
-> **Snapshot: 2026-10-01 16:45.** This is a dated public status page, not live
+> **Snapshot: 2026-10-01 16:47.** 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:
@@ -47,10 +47,17 @@ meant to execute on the physical GPU.
closed the host side: it reads none of the remaining host-supplied fields
(the one registry key on its call graph can only clear an error), so the
ACPI/workspace/zeroed-field leads are retired. The one hard dependency left
- on the failing path is a **PMU-provisioned encrypted device identity** (no
- message-queue field or host path supplies it), so the next leads are the
- PMU initialization/ucode stage and deeper server-log visibility. Each of
- cycles 4-10 released the device cleanly with no reboot. |
+ runtime is enabled only after the collector and the protected region blocks
+ host reads). **Cycles 11-13 resolved this wall**: the resource-manager log
+ ring had never actually been mapped (its libos init-argument id was
+ malformed), which is why the first error was invisible; with the ring live
+ the failure traced to the server's chip device-id reading as zero because
+ the pre-boot identity fields were sent unpacked instead of as raw PCI
+ config-space dwords. Fixing the payload made the server report init-done
+ with a zero result and serve the full static-config reply (GPU name, 8 GiB
+ FB, internal handles, BAR PDE bases, engine caps), and graceful shutdown
+ works through the unload RPC. Each of cycles 4-13 released the device
+ cleanly with no reboot. |
| Graphics (3D), video | ❌ |
| Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
@@ -137,19 +144,13 @@ chain succeeds.
a display-disable experiment showed display is not the first error. The
collector's failing step is not visible in the server journal (its log ring
is enabled only after the collector, and the protected region blocks host
- reads). A source-level review has now **closed the host-side input
- campaign**: the collector reads none of the remaining host-supplied fields,
- all earlier leads (device-id override, display key, ACPI method data,
- video-memory workspace branch, zeroed fields) are exercised or retired, and
- the only hard dependency on the failing path is a server-PMU-provisioned
- encrypted chip identity that no message-queue field or host RPC supplies.
- Next leads, ranked: (1) the PMU initialization/ucode stage - determine
- whether a host-driven boot must stage it or the server provisions it
- itself; (2) server-log visibility - repair the resource-manager log ring
- mapping (enabled only after the collector) so the server's first error
- becomes readable, with a memory-read fallback if the protected region
- allows; (3) if neither, treat it as a server-side firmware-instrumentation
- problem and record it as such rather than adding more host fields.
+ reads). A source-level review had **closed the host-side input campaign**
+ and named a server-PMU dependency as the one hard requirement. **That
+ verdict was superseded by cycles 11-13**: the log ring was in fact never
+ mapped (its init-argument id was malformed), and once it was registered the
+ failure was a zero server-side device-id caused by our unpacked identity
+ payload - the PMU path itself was fine. The raw config-space identity fix
+ completed initialization (see the milestone bullet above).
- **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