From 0c5c218201ceba738371dda286a58eff0cb60191 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Wed, 30 Sep 2026 12:55:57 -0400 Subject: STATE-CURRENT: quiet logging landed; baseline verified twice; PD-capture task next - dmesg diagnostics gated behind default-off sema_dbg; 64/64 with a 520-line log - staging buffer kept resolvable via streamed pins; PD-entry capture remains - note the guest-side kernel fault observed in serial --- STATE-CURRENT.md | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) (limited to 'STATE-CURRENT.md') diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 0959c39..0c8cef7 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-09-30 12:42.** This is a dated public status page, not live +> **Snapshot: 2026-09-30 12:55.** 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: @@ -53,12 +53,13 @@ chain succeeds. class transfer bound on a compute channel whose work was denied by the engine-type gate; trusted host-injected pushes may now execute copy-engine work as well). -- **The baseline is restored (payload roundtrip 64/64 again)**: with the - page-table publication capture in the running module, the device-to-host - copy's destination resolves and the roundtrip matches exactly (verified - live at 12:41). The regression was the guest's live page-directory entries - not reaching the emulated shadow; capturing and promoting them fixes the - walk for client system-memory addresses. +- **Baseline green and quiet**: the payload roundtrip is back to 64/64 + (`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. - 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; @@ -66,15 +67,18 @@ 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: land and document the page-table capture fix, then re-run the - static-runtime `vectorAdd` client and chase its remaining delivery/deadline - wall. +- 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. - 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. - Guest health note: agent/SSH timeouts during long runs are the guest-side trace reader flooding the ring; they recover on their own, so a first - timeout is not a reason to restart the VM. + timeout is not a reason to restart the VM. A guest kernel fault appeared in + the serial log during the latest cycle (guest-side; host stable) and is + under investigation. - Execution backend (chosen, not started): the module will own the physical GPU and run its real GSP firmware as the resource-manager server, so real work executes with an unmodified host driver and no host daemon; see -- cgit v1.2.3