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

1 files changed, 15 insertions, 11 deletions

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