summaryrefslogtreecommitdiffstats
path: root/STATE-CURRENT.md
diff options
context:
space:
mode:
Diffstat (limited to 'STATE-CURRENT.md')
-rw-r--r--STATE-CURRENT.md26
1 files changed, 18 insertions, 8 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 0c8cef7..6712b77 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
# Open-IOV Current State
-> **Snapshot: 2026-09-30 12:55.** This is a dated public status page, not live
+> **Snapshot: 2026-09-30 14:02.** 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:
@@ -57,9 +57,10 @@ chain succeeds.
(`ALL OK`), the staging buffer's translation stays resolvable via pins
streamed from the guest, and high-frequency diagnostics are now gated
behind a default-off debug switch - a normal boot+run produces a ~520-line
- log instead of a flood (verified twice). The deeper page-table question
- (capturing the guest's page-directory entry writes into the shadow so the
- walk resolves system memory without pins) is the next task.
+ log instead of a flood (verified twice). The page-directory entry writes
+ have since been captured live and validated (the earlier all-zero boots
+ were operation-skipped/pre-pin boots); the remaining question is the
+ device-address walk gap for the runtime's own buffers.
- Recap of the fixes behind this point: all 20/20 compute-channel releases
land (three decode paths routed to the exact counter slot); registration
delivers the incrementing tracking release for every consumed submission;
@@ -67,10 +68,19 @@ chain succeeds.
the copy-engine decoder consults pinned translations before the scanned
map, so every push-data operation executes (`memset=19473`, `ringops=10551`
live).
-- Active work: capture the page-directory entry writes (destination-keyed,
- debug switch on) and promote them into the shadow so the walk resolves
- system-memory addresses without pins; then re-run the static-runtime
- `vectorAdd` client.
+- **Runtime client status**: the static-runtime `vectorAdd` client is now past
+ the registration/tracker wall - the host's releases land, UVM observes the
+ completed wait and registration returns success. It still returns an
+ initialization error a few hundred milliseconds later, with no kernel-side
+ error; that post-registration failure is in libcuda and is being traced.
+- **One real emulation bug fixed**: the BAR-info control replied with the
+ wrong parameter size, so the guest's reply cache rejected it; the canonical
+ struct is now returned. One cache-set mismatch remains once per boot and is
+ being identified.
+- Active work: identify the remaining reply-cache mismatch, capture the
+ runtime client's post-registration stack if needed, and close the
+ device-address walk gap for the runtime's own buffers before attempting
+ allocation/kernel launches.
- 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.