| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
committed, module e7ff3bf7, campaign 239-262 validating)
|
| |
|
|
| |
Refresh the status page: the acceptance is holding under hardening (per-op once bitmap, epoch/content-hash gate, 15 s CE grace; first-attempt 86% -> ~94-95%, fakes/run 3.39 -> 0.61), the hold-all-unreadable experiment is live, and the residual classes are named (late-decode corruption, early UVM channel-manager stall, guest init panic). Add an options section listing candidate techniques that would accelerate debugging toward end-to-end CUDA (deterministic fault injection, offline pump model, structured host tracing, guest-memory forensics, GR-wall metadata/golden reference/static-analysis throughput, cheaper supervised cycles, concurrency checks, tooling automation) - explicitly not directives, each requiring an eng-ops admission record.
|
| |
|
|
|
|
|
|
|
|
| |
pre-rescue fake
An unreadable CE entry whose channel already had a decoded release VA was faked immediately and consumed with no log line, before any rescue attempt. A later pin-batch rewind then executed the skipped copy against a staging buffer the client had since refilled - the deterministic vadd input shift seen in runs 94/122/151/173b/215b, each with a silent pre-rescue fake.
Now every unreadable CE entry with an expected payload is held for the bounded grace and the rescue is retried on each pass, so a translation that is still coming wins and the work runs before the release. Only an entry whose release was already delivered (the channel moved past entry_want) is consumed at once; the post-rescue fake remains the bounded, visible escape. The CE grace default moves 15000 -> 25000 ms (a translation arrived ~17 s after first examination in 215b).
Under live campaign 229-236 (module 97eba5b7; green so far).
|
| |
|
|
| |
external-VAS vaList gate, rec-677)
|
| |
|
|
|
|
|
|
|
|
|
| |
A consumed entry's work is never run; if its release lands via the
fallback before the entry's copies have executed, the client refills the
staging slot the copies then read (observed as the deterministic
one-chunk vadd input shift). Keep untranslatable CE entries pending
longer so their copies run before any release reaches the client.
8-cycle pilot (141-148): zero corruption; a red-fingerprint cycle
(held=1165, ring_auto=6) healed to ring_auto=26 with faked=0 and the
exact checksum, where the 8 s window recorded 1 corruption in 36.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
content-hash once gate)
The grace-expiry fake path consumed a held CE entry without marking its
GPFIFO slot as consumed for the put epoch, and the replay guard only ran
while the channel was not deferring. A later pin-batch rewind then
re-read the slot, found no recorded identity, and executed the push's
copies against a staging buffer the client had refilled after the faked
release - a deterministic vadd input shift (a[k] == h_a[k + 2 MB]).
- grace-fake consume path now calls svc_replay_note() before advancing;
- the svc_replay_seen() replay skip is evaluated unconditionally: a slot
consumed in the current epoch is skipped on every replay, deferral or
not, until a put wrap clears the mark;
- the once-only identity gate gains a content witness (FNV-1a hash of the
recorded push bytes): the same entry words with different push content
is a new push (clients rewrite push buffers in place) and runs its ops
with a cleared done bitmap; suppression requires identical content;
- snapshot write-back persists the hash array; new drain counter
reident= counts content-mismatch cancellations;
- the grace window stays at 8 s: a faked entry's work is never run, so
the hold is that work's only chance (a 2.5 s experiment made red-class
runs complete with corrupt data instead of timing out).
Verified: module 8e90fc7e..., three consecutive end-to-end acceptance
runs (MAIL + VADD bad=0 checksum=392344090.500000 + STATUS OK).
|
| |
|
|
|
|
| |
A later supervised cycle reproduced the held-entry retry over a
refilled staging buffer, the completed operation was skipped, and the
end-to-end transfer verified byte-for-byte (bad=0, expected checksum).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pump's operand-targeted-scan hold decodes a push, runs every op that
translates, then leaves the entry pending for a retry. The retry
re-decoded the whole push and re-ran the operations that had already
completed. A CE copy reads a client staging buffer the client refills
per chunk, so the retry overwrote a finished chunk with the following
chunk's data (observed: the bridge's vadd input half replaced by the
next 1 MB chunk, first half of the device buffer byte-identical to the
source shifted by exactly 2 MB; the same 1 MB copy logged twice with
different staging contents).
The service now records, per GPFIFO slot, the entry identity plus a
bitmap of the decoded operation indexes whose work has executed for
that identity, and a complete flag for a pass that ended with no
operand pending. svc_run_ops skips already-executed ops on a retry and
marks the rest as they succeed; the pump stores the record
immediately after decode, before any hold path can break, so the
pending path can no longer lose it. A replay of a complete identity
suppresses all ops; a partial identity retries only what is owed.
Also carries the ops_once diagnostic counter in the service snapshot
line and documents the operation-granularity rule in the architecture
doc.
|
| |
|
|
|
|
| |
simulator wave
Simulator development wave (docs 42-44): GMMU page-table entry decode with its oracle/workflow harness, FBIF observability, and MPU/LIBOS device surfaces in the device model, plus refreshed boot/machine/profile data (tu104-570.144), the qemu-line results, and the new unit tests. Docs 00/06/35-41 updated to match; harness helpers and .gitignore included.
|
| |
|
|
|
|
| |
The entry-identity gate suppresses every operation on a replayed entry, but an entry held because one operand's targeted scan was still running is decoded again on retry, and the ops that already succeeded would re-run against a staging buffer the client has since refilled (observed: a retried HtoD wrote the second vadd input half into the first).
Track a per-slot bitmap of the operations (0..63) already executed for the slot's current entry identity, plus a complete flag for the pass that finished with no operand pending. On replay, a complete entry suppresses all ops; otherwise the bitmap decides per operation. Successful fills/copies set their bit, and the skipped count is published as ops_once in the drain line.
|
| |
|
|
|
|
| |
acceptance; 14/15 repeat cycles green)
Refresh the public status page for the 2026-10-04 acceptance: noclaim38/39/40 report MAIL + VADD n=1048576 bad=0 checksum=392344090.500000 + STATUS OK with identical hashes (committed aa3520f2); the repeat campaign shows 14 of 15 green with the remaining failure the known intermittent guest-side flake. Update the milestone ladder (CUDA kernel execution now green via the no-claim host bridge; guest engine forwarding to the physical GPU still the open backend wall) and the milestone index/log.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The no-claim emulation path now runs a stock CUDA program end to end:
device properties, cudaMalloc, a GPU-authored string kernel read back
byte-for-byte, two 4 MB host-to-device copies, a 1 M-element vectorAdd
executed on the physical GPU through the host bridge, and the
device-to-host copy-back verified element by element. Three consecutive
supervised cycles report MAIL + VADD bad=0 checksum=392344090.500000 +
STATUS OK with identical input/output hashes.
Two data-path correctness fixes make the transfers sound:
- Once-only op execution per GPFIFO entry. The pump replays recently
consumed ring entries when translation batches are injected so missed
releases can land; re-executing a CE copy is not idempotent because
its source is a client staging buffer that may have been refilled.
Slots now record their raw entry words and a replayed entry matching
that identity suppresses operations while still processing releases.
- Per-page translation of virtual operands. svc_copy resolved only the
first page of a VA range and walked the PA linearly; client staging
ranges are frequently split (observed 195 + 61 pages), so the tail of
alternating chunks was read from unrelated memory. Multi-page copies
now re-resolve each 4 KB page through the trusted resolver.
Also carries the earlier uncommitted emulation fixes that got the client
to the launch (QMD address-window gate, counter registration
persistence, 512 MiB emulated FB, bridge slot hygiene) and bounded
diagnostics (sema-bigop, sema-bigcopy, bridge-in/out hashes, daemon
INCHECK/OUTCHECK/dumps).
|
| |
|
|
| |
vectorAdd launch; mail read-back fixed; bridge slot oops + approved reboot; post-reboot run blocked by guest boot panic)
|
| |
|
|
| |
Xid recovery, GPU-only VA->PA wall)
|
| |
|
|
|
|
|
|
| |
- kernel: gsp_cuda_bridge (QMD launch capture, debugfs job/out/done, param+output resolution cached from inline writes), sema drain fixes (never hold/starve a channel), GR ring autopin + counter autoreg, per-page push reads, counter-derive gate; module builds clean
- tools/cuda-bridge: CUDA driver-API daemon executing mail/vadd kernels on the physical GPU, CUBB2/CBD2 v2 protocol, layout check + self-tests
- tools/guest-diag + tools/cuda-ab: scanner/pin fixes, victory push-only mode
- debug/risc-v-gsp-rm-vm: Phase S simulator wave (GSP device model, boot ladder, triage/re-demo harnesses, docs 30-41), GPGPU-sim scaffolding
- STATE-CURRENT/docs updates
|
| |
|
|
| |
exercised against the physical backend; reaches device properties then stalls in UVM channel path)
|
| | |
|
| |
|
|
| |
VAS; shared-VAS opens 0xc5c0 object-alloc wedge; host in locked fail-safe pending reboot approval)
|
| |
|
|
| |
cleared by approved reboot; commit/RAMFC wall unchanged)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(guest-faithful 9-entry set)
- gsp_rm_emulation: dump every guest GPU_PROMOTE_CTX (0x2080012b) params and
entries so the real client's promote shape is observable (captured on the
emulation path: MAIN 2 MB PA+VA, PATCH, BUNDLE_CB/PAGEPOOL/ATTRIBUTE_CB/
RTV_CB_GLOBAL VA-only, FECS, PRIV, UNRESTRICTED)
- gsp_phys_booter: promote mode 19 replays that exact 9-entry shape on the V5
channel with host buffers (MAIN 2 MB + PDB map, small buffers, booking-only
VAs); clamp 0..19
- docs/eng-ops: mode-19 result recorded - the server never replied (fn76 -110)
and the release fail-safe held WPR2/GPU until an approved reboot; mode 19 is
known-wedging
|
| |
|
|
|
|
|
|
|
|
|
| |
- gsp_phys_booter: mode 18 allocates a FERMI_CONTEXT_SHARE_A (0x9067) on the
TSG with the ladder VAS and carries it as hContextShare on the V6 KMD
channel, so the share construct can allocate the GraphicsSubcontext the
single-MAIN promote needs; clamp 0..18
- docs/eng-ops: GR promote bisection row updated with the session-2 results
(modes 12-18: PA-only accepted but no ENG_CTX_VALID; PATCH/PM/FBMEM and
server-managed registry all leave the KMD promote at 0x40; wall is the
commit/RAMFC path)
|
| |
|
|
| |
commit/RAMFC wall)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
registry variant; complete vgsp rename; docs/tooling refresh
- gsp_phys_booter: GR promote bisection modes 4-17 (two-phase zero-field VA,
batched entries, hVirtMemory, bare VA, KMD SKIP_CTXBUFFER_ALLOC channel,
old-interface GPU_INITIALIZE_CTX, FBMEM context buffer, UVM-faithful PA-only,
PATCH/PM auxiliary promotes, server-managed no-promote path); PATCH/PM
geometry queries and buffers; pre-boot SET_REGISTRY profile selection
- gsp_phys_gpu: gsp_phys_rmcall_gr_promote clamp 0..17 and gsp_phys_srv_ctxbuf
parameter; registry image variant with RMSetClientRMAllocatedCtxBuffer=0
- vgsp rename across kernel, scripts, tools and docs (module vgsp.ko,
/sys/kernel/debug/vgsp/, vgsp-<subsystem>: log prefixes)
- risc-v-gsp-rm-debugger user-facing rename and docs/CI refresh; guest-diag
tool updates; README/SBOM/install/Makefile sync
Live status: CE ladder and P6 guest-copy forwarding green; GR engine context
commit still open (all promote shapes accepted or cleanly refused; the channel
stays CTXNOTVALID) - see Handoff-vGPU-IO.md Addendum 21 (local).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
complete rename, adversarial-review fixes
Remove the '# TOOL IN DEVELOPMENT - NOT READY YET!' notices from the tool docs/README/scripts and the project docs; record the removal (2026-10-02) against the tool audit (debug/risc-v-gsp-rm-vm/docs/27-TOOL-AUDIT.md), the 194-test suite and the value-validation demos (docs/25-VALUE-VALIDATION.md).
Complete the cosmetic rename to risc-v-gsp-rm-debugger in user-facing prose and commands (launcher, roadmap, docs); internal greeneye package and code identifiers unchanged.
Adversarial-review fixes: deterministic control-discovery sweep (flaky test root-caused), UUID session dirs + atomic JSON writes for concurrent runs, Ghidra bridge loopback enforcement and clean shutdown, fp register restore in Session.call, version_diff --dry-run, 30 s interrupt budget, dry-run non-destructiveness verified.
Docs: flag-removal records, link fixes, command/flag corrections (fdematch arity, port_new_device --out, trace filename), F2 orchestration note in future-eng-ops; STATE-CURRENT status refreshed.
|
| |
|
|
| |
docs, CLI, launcher and CI workflow; internal greeneye package/module identifiers unchanged (includes in-flight greeneye module edits present in the tree)
|
| |
|
|
| |
scripts, simulator packaging, porting docs; control-discovery fix
|
| |
|
|
| |
untracked; drop built RM tool binaries (source and Makefiles stay)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- docs/eng-ops.md gains Part II, live physical-backend engineering
operations: hard rules, the full module-parameter matrix, the routine
supervised cycle and clean-release checklist, the debugfs inventory,
how to read gsp-phys-state, a debugging scenario catalogue
(CTXNOTVALID/promote wedge, fail-safe WPR2, unload hangs, guest wedges,
MMU/PTE and PBDMA faults, relay symptoms), a hazard register (crash
causes and debugging side effects), the physical-backend OODA loop, and
the work-context map with porting flows
- architecture, implementation, operations, orientation, getting-started,
portability, ecosystem and reference docs corrected to the current
state: CUDA driver-API smoke green, CE-class work forwarding and
engine-authored releases plus fault relay in place (default off), GR
execution blocked on engine-context validity, the promote wedge and
designed locked fail-safe, and P5 wave-2 subsumed
- internal-reference cleanup in tracked docs (no analysis-source or
local-archive references); historical architecture document bannered
- README reading list and STATE-CURRENT frontier refreshed; new pages
(runbook, green-eye user guide, porting sequence, porting/packaging
notes) linked from the tree
Link check: scripts/check-docs-links.py passes (56 files, no broken links).
|
| |
|
|
| |
plugin, value-validation demos, CI pipeline, toolchain docs; add host RM tools rmtool/rmtop
|
| |
|
|
| |
(default off; live-unverified at promote)
|
| |
|
|
| |
fail-safe hold, green-eye wave 2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bridge, long-term docs
Adds to debug/risc-v-gsp-rm-vm/:
- Session.call / run_until: Frida-like remote function calls and run-to-cursor,
with register restoration; verified live (rpc_ping -> 0xaffe).
- symbol+offset target resolution (gsp_ctrl+0x10) across all APIs and the REPL.
- Injection SDK (sdk/) and 'greeneye inject': position-independent RV64 service
blobs (verified zero relocations), loaded into RAM, registered in the demo
handler table, and invoked either directly or through the firmware mailbox
dispatcher. Demo ABI extended: mailbox 16..23 selects slots, arg0 carries the
service command, arg2 added (struct now 0x190; schema updated).
- Ghidra control bridge (greeneye ghidra + GreenEyeControl.java): run-until-here,
breakpoints, memory/register access, remote calls, hit export; verified
end-to-end with Ghidra headless (run_until reached rpc_sum from a GhidraScript).
- MarkGreenEyeHits.java fixed for the Ghidra 12 createBookmark API; verified
headless together with ExportForGreenEye.java.
- Analyzer renders a QEMU first-fault table for probe sessions (fault count,
epc with firmware vaddr translation, access address/size, reason).
- Tests now 35 green, including injection, Ghidra bridge, remote call, run-until
and REPL command smoke tests.
- Documentation: docs/11-16 (GSP RM service developer guide, injection SDK
specification, Ghidra control, adversarial interoperability guide, agentic
GSP IDE, custom simulator design) and GREEN-EYE-ROADMAP.md (long-term H1-H7
program); doc maps and the project RISC-V VM doc updated.
|
| |
|
|
| |
wall, green-eye tooling
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- the work_relay state line now reports the real backend data-compare
verify_fail plus a verify_transient count, distinct from the sema-service
hold re-read verify_fail (previously the backend counter was dropped)
- a relayed copy whose host-side compare fails is re-read and re-compared
once after a short delay; a transient mismatch counts as success and only
a persistent mismatch falls back to the software apply as before
- the final-mismatch diagnostic now logs the semaphore target/payload/poll
time, the first differing byte and 16-byte dumps of live dst, live src and
a submit-time analysis material, flagging source mutation vs snapshot/dst
- the fault no_event path logs the post reason/return
All changes are behind the default-off relay path.
|
| |
|
|
|
|
|
|
|
|
| |
Adds open-iov/debug/risc-v-gsp-rm-vm: a GDB-free instrumentation stack that boots uproc/GSP firmware in qemu-system-riscv64 and provides Frida-like hooks, breakpoints, watchpoints, memory dumps, structure decoding, snapshot diffs, recorded sessions, declarative probes, a plugin API and a Ghidra symbol/hit bridge.
Verified: 25 tests green (including a live QEMU smoke test); the demo uproc boots with correct hook/leave/watch/schema/snapshot/fault evidence; the optional TCG trace plugin builds and recorded 15M trace lines in 3 s; the TU104 570.144 fwimage probe reports its first exception (load access fault at firmware vaddr 0x4009014 reading 0x2000000000000A00).
Documentation: lean tool docs under debug/risc-v-gsp-rm-vm/docs/00-10, a new docs/05-operations/03-risc-v-gsp-rm-vm.md debugging document, and '# TOOL IN DEVELOPMENT - NOT READY YET!' markers in docs/README.md, the onboarding tooling table and the debugging workflows doc.
Vendors qemu-plugin.h from QEMU v8.2.2 (GPL-2.0-or-later), with its license header intact, so the optional TCG plugin builds without a QEMU source tree.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New load-time gsp_phys_rmcall_engine (0=COPY0 default, 1=GR0) parameterizes
the physical ladder: TSG and channel engine_type GR0, one-attempt channel
alloc, TURING_COMPUTE_A engine object (class 0xc5c0, handle 0xcaf0002c),
BIND engineType=1, and a GR method push (SET_OBJECT 0xc5c0 on subchannel 1
plus SET_REPORT_SEMAPHORE) submitted through the existing GPFIFO/USERD
doorbell tail, polling the module semaphore. CE work-forwarding refuses
cleanly while a GR ladder is active. A debugfs trigger re-runs the GR push.
With the parameter at its default the ladder emits byte-identical COPY0
requests (only the state line gains engine=COPY0).
Live (first GR context on the live server): every GR RPC accepted -
channel variant V5, TURING_COMPUTE_A alloc status=0x0 -> hObject=0xcaf0002c,
BIND status=0x0, token=0x1 - and the engine fetched the push (GPGet 0->1),
but raised a GR exception instead of executing the release:
exceptType=0x20, NOCAT faultingEngine="GR", intr1=0x80000000, no rpc_result
errors. The failure is downstream of all RPCs; no mutating retry was made
and the device released cleanly (WPR2 down, rebound, 5 locks, pstore empty,
same boot). A default-engine control cycle stayed green (REAL COPY OK).
Follow-up: bisect the GR alloc params, the release method D word, and the
method order/context init using the drained GR fault records as the oracle.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New default-off gsp_phys_fault_relay: when a relayed copy times out, the
GSP-RM status queue is drained and the first OS_ERROR_LOG (0x1006) recorded
after the submission's doorbell is decoded (NOCAT corroboration), matched
against the ladder channel's runlist/chid, and delivered to the guest by
writing its channel notifier (info32=exceptType, info16=engine type,
status=0xffff) and posting the channel event. A late-release recheck skips
delivery if the engine actually completed, one delivery per hold, and the
existing software fallback always runs first, so no release or data is lost.
- pure decode helpers extracted from the status printers; prints unchanged
- status-queue walks serialized with a mutex; unmatched 0x1006 records are
no longer silently dropped
- fault epoch snapshot at the doorbell prevents stale records from matching
- fault counters and faults:/fault_relay: state lines
- default-off gsp_phys_fault_inject debug knob forces the next relayed
pair's source PTE to zero to produce a real engine fault
- pump notifier latch prevents clobbering a delivered fault
Live: injection run produced a real CE0 FAULT_PTE (0x1f @0x200000), decoded
with errString, chid/runlist matched, notifier delivered, software fallback
applied (applied+fallback==engaged), clean release; the guest RM reacted to
the delivered fault by tearing down its channels (faithful semantics).
Healthy control: faults all zero, relay requested=40 ok=40, smoke
matched=64/64, clean release. Caveat: the auxiliary event post failed
(no_event=1, no MSI-X) and the guest teardown means fault injection is not
smoke-compatible; the parameter stays off.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New default-off gsp_phys_relay: for a forwarded guest CE copy whose push
ends in a one-word release, the release page is resolved at forward time,
mapped on a fresh scratch line, and the real engine writes the payload
directly into the guest-visible semaphore page; the deferred-release hold
then verifies that page and skips only that record's software apply. Any
failure (unresolvable target, refused kind, pool exhaustion, poll timeout,
data mismatch, channel teardown) falls back to applying every release in
software, so a release is never lost or duplicated.
- new exported gsp_phys_backend_guest_ce_copy_ex() + relay counters;
gsp_phys_backend_guest_ce_copy() behavior unchanged (wrapper)
- new work_relay: counters line in gsp-phys-state
- relay limited to CE channels and one-word absolute releases; counter
and reduction releases stay on the existing paths
Live: param-off regression matched the wave-2 baseline exactly (req=101
ok=101 verify_ok=101, copy_skipped=119, smoke matched=64/64, relay zeros).
With the parameter on: requested=68 ok=67 skipped_sw=67, verify_fail=0,
resolve_fail=0, timeouts=0, smoke 64/64, and the engine-authored guest
semaphore was observed directly (sem=0x00000003 / 0x0000007e at the guest
page). One copy in 68 released its semaphore but failed the host-side data
compare; it fell back to the software apply (fallback accounting
applied+fallback==engaged) with the smoke green - residual to triage, which
is why the parameter stays default-off. A forced-unresolvable run
(requested=103, fallback=105, no relay submissions) kept the smoke green.
Every cycle: 5 power-domain locks held, driver rebound, WPR2 down, no rail
cycles, pstore empty, same boot.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Triggers 6 (W2G) and 7 (G2H) previously used page-table slots pre-built once
during the ladder's stage 3. A guest page's host physical address can change
between translations (observed 0x13a591000 -> 0x3b8318000 for the same GPA),
and a runtime PTE rewrite into an already-fetched 128-byte line is invisible
(no invalidate path), so the later write-direction trigger validated against
the wrong page and failed its data check.
Both triggers now translate at trigger time and run through the same
fresh-scratch-line path as forwarding, via a shared internal copy body; the
exported forwarding API is unchanged and still requires
gsp_phys_work_forward. A changed HPA is now an informational once-per-boot
note rather than a failure; the probe-pattern guard still refuses stale pages.
Trigger 8 and the stage-3 pre-built slots are unchanged.
Live (run p6w3): GUEST G2H COPY OK gpa=0x12423d000 hpa=0x56ab3a000;
GUEST W2G COPY OK with verify_ok=1; PTE selftest OK; guest SEEN_W2G; ladder
REAL COPY OK; clean latched release (5 power-domain locks, rebound, WPR2 down,
no rail cycles, pstore empty, same boot). The full smoke run hit the known
guest cuInit/WPR2-already-up wedge at cdt; the trigger path itself is green.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copies
- new default-off gsp_phys_work_defer_release: a forwarded guest push's
releases are recorded and its GPFIFO entry is held (no consume, no
GP_GET write, no counter publish/stall) until the work item publishes
completion; the service thread then delivers the releases, with a
fallback on failure/timeout (500 ms cap enforced every pump pass)/
pause/quiesce/channel-delete
- new default-off gsp_phys_work_hw_primary: the software copy is skipped
for forwarded ops, so the physical engine authors the data; a once-only
software copy runs before the releases on any hardware failure or when
the request cannot be queued
- release-apply helpers extracted; exactly-once latches; channel-delete
and teardown handling; counters and a work_guard state line
- live: deferred-release run engaged=75 applied=75 timeouts=0 with the
full smoke green; hardware-primary run req=100 ok=100 verify_ok=100
fallback=0 copy_skipped=119 copy_fail=0, smoke ALL OK 64/64 (guest read
data the engine authored), with 19 fail-closed inline software
fallbacks under single-inflight contention; a range-unregistered run
proved the fallback (121 skipped copies, all recovered, smoke green)
- defaults off; the software path and all existing guards unchanged
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- the sema service captures the first eligible copy per push from the
software resolver's own operands (the real push shape mixes guest RAM
with emulated-VRAM shadow addresses, including physical destinations)
- HPA resolution: guest RAM through the shared guest-RAM file page cache,
emulated VRAM through the mapping of its kernel shadow
- new scratch page-table pool: 16 zeroed page-table pages with their
page-directory entries built before any engine access, handing out one
whole 128-byte GMMU PTE fetch line per copy pair (16 PTEs, 512 pairs
per boot, never reused; a PTE written into an already-fetched line is
not observed and there is no invalidate path)
- the backend submits the copy on the module-owned channel and verifies
the result host-side; every miss falls back to the ladder shadow copy,
and the software pump remains authoritative
- live (full smoke, both parameters on): req=42 ok=42 verify_ok=42
verify_fail=0 fallback=0, guest payload roundtrip ALL OK 64/64,
clean latched release; defaults stay off
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- file-backed guest RAM (launcher memory-backend-file share=on) and
in-kernel GPA->HPA translation through the shared file page cache
(read_cache_page + page_to_phys + pfn_valid), opened O_LARGEFILE;
new default-off gsp_phys_guest_mem parameter
- debugfs gsp-phys-guest-ram (path + gpa/off/size ranges) and
gsp-phys-guest-gpa (one pinned GPA per boot); rm-call triggers 6/7 run
host->guest and guest->host 4 KiB CE copies; trigger 8 is a PTE
self-test through a fresh slot
- guest page-table slots are pre-built during ladder stage 3: runtime
PTE writes into an already-walked page-table line are not observed
without a TLB invalidate
- guest RAM layout (q35 4.2, 4 GiB): below-4G GPA == file offset,
above-4G offset = GPA - 0x80000000 (2 GiB PCI hole)
- tests: tools/test/gpage_test.c guest probe; docs + STATE-CURRENT
record the live green (G2H/W2G with semaphore release, guest observed
the write, smoke ALL OK 64/64, clean latched release)
|
| |
|
|
| |
third-party references
|
| | |
|
| |
|
|
| |
P5 wave-1 shadow execution
|
| |
|
|
|
|
|
|
| |
- STATE-CURRENT snapshot moves to the P3 frontier: the host-freeze latch
and readiness gates are validated, the static identity overlay and the
read-only control forwarding are landed and live-verified
- the physical-backend guest-wiring design is now marked P0-P3 implemented
with the P2/P3 acceptance results
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Host-freeze fix bundle (validated 2/2 supervised cycles):
- power unlock now latches D0/D3cold by default (new gsp_phys_repower,
default 0); releasing the claim can no longer power-gate the board and
hard-freeze the host on resume
- bounded post-rebind readiness gate before dropping the locks; bounded D0
settle/verify before the unbind
- READY means a live GSP-RM session: the async worker and the module-owned
join only expose READY when init-done is seen and no unload was sent;
otherwise the claim is released fail-open
- FWSEC reads DMEM0/IMEM back before STARTCPU and fails fast when the
staging is not visible
- the claim harness leaves the board latched by default and takes
--restore-power to opt back into the old restore
Guest-wiring:
- P2: generation-keyed fn65 static-config snapshot cache plus a default-off
identity overlay (new gsp_phys_static_live) for name/short-name/VBIOS;
the probe cycle runs once per backend generation at READY
- P3: default-off read-only RM_CONTROL forwarding whitelist (new
gsp_phys_ctrl_forward) with emulated-handle translation to the adopted
server handles and full emulation fallback
- P5 wave 1: default-off shadow execution of guest CE pushes on the ladder
channel (new gsp_phys_work_forward) via a dedicated ordered work item;
the ladder stage-4 submission is refactored into a shared bounded helper
and the software release path stays authoritative
Live: module-owned boot to init-done, guest smoke ALL OK 64/64 with P2/P3
enabled, 514 shadow copies observed on the physical CE; all cycles released
cleanly with WPR2 down and no reboot.
|
| |
|
|
| |
identity overlay live (GREEN); LIVE=0 control did not pass
|
