| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a default-off guest GR (compute) forwarding path so a guest CUDA
launch submitted on its GR channel can be executed by the physical GR
engine on the ladder channel, with fail-closed fallback to the host CUDA
bridge and the unchanged software release path.
- New module parameter gsp_phys_gr_forward (default 0) and accessor.
- New GR execution gate: boot_stage.rmcall_gr_exec_ok, latched only after
a real GR submission logs REAL GR SEM OK; the backend refuses while it
is unset.
- Sema capture: a completed 64-word inline QMD on a trusted, non-replay
GR decode becomes an svc_gr_cand (push identity, decoded release0,
parameter/program/pointer fields, up to 8 captured inline-write
records); the CUDA bridge stays authoritative while the parameter is
off and is reached in order forward -> bridge -> software release.
- Backend: gsp_phys_backend_guest_gr_submit() maps pages at their own
guest VAs through fresh Tier-1 small-PT pages/PDE installs or relocates
inline-captured pages to ladder shadow pages (Tier 2), builds
SET_OBJECT + the inline-QMD method run + REPORT_SEMAPHORE on the
compute subchannel, reuses the shared GPFIFO/USERD/doorbell publish
tail (extracted from the CE submit path, CE bytes unchanged) and polls
the QMD release and/or module semaphore, draining the epoch-gated
fault queue on timeout.
- Sema wiring: GR requests reuse the INFLIGHT/hold/deferral machinery so
the guest channel release applies only on the submit's success/failure
edge; hold shims preserve the channel engine type.
- Counters and a work_gr state line plus a stats accessor.
- Bounds are fixed: 16 pages, 8 inline records, 64 QMD words; every
pointer/size checked, pool exhaustion and stale mappings fail closed.
- New ABI layouts pinned with static_asserts.
Compile-only change: no device test performed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- NV2080_CTRL_GR_CTX_BUFFER_INFO is 80 bytes (NvBool is NvU8: flags at
56..59, uuid at 60) and the params are 5136 bytes, not 5648; the previous
ABI mismatch is why GR_GET_CTX_BUFFER_INFO returned NV_ERR_INVALID_ARGUMENT
(0x1f) on every shared-VAS cycle.
- Under gsp_phys_srv_ctxbuf the GSP-RM server allocates/maps/commits the
engine context itself: do not install the client GR context-window PDEs and
do not map the client ctx VA in the PDB, so a client mapping cannot clobber
the server's own context-window page table.
- Dump the server-written INSTANCE/RAMFC chunks after BIND/SCHEDULE on the
shared GR path so the committed engine-context pointer/VA can be located.
- Emit the full NOCAT diag buffer as 16-byte hex rows (the printable copy is
capped at 192 dotted bytes and hides binary fault dumps).
Untested on hardware at commit time; the next supervised GR cycle validates.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 708a3802 per-type VRAM change stripped an nvidia- prefix from
mdev->type->sysfs_name, but sysfs_name is the registered type name
verbatim; the mdev core only prefixes the type DIRECTORY with the parent
driver string. Every lookup failed, so all mdevs silently fell back to
512 MiB, nvidia-vgpu-turing-1g was unreachable and available_instances
capped at 1. Match sysfs_name directly in get_available,
show_description and mdev_create.
Also canonicalise the NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE encoder
(BAR0+0x100ce0) by stripping factors of two from MAG so 512 MiB encodes
0x19 again (1 GiB 0x1a, 2 GiB 0x1b) instead of the non-canonical 0x204.
Default-512M behaviour is now byte-equivalent to the known-good pre-VRAM
module except max_instances=2. Module sha256 cb1724d3.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- nv_vgpu_type_info/ioctl gain vram_mb; nv_vgpu_device gains fb_emul_size
bound from the mdev type at create (default 512 MiB).
- New nvidia-vgpu-turing-1g type (1024 MiB); turing max_instances 1 -> 2;
show_description reports the per-type framebuffer and max_instance.
- Thread fb_emul_size through GSCI fb_length/region/frtsOffset, WPR2,
NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE, the vidmem allocator bound and the BAR1
shadow; bar_info callback uses the per-device size.
- UNTESTED at commit time: builds clean; validation blocked by the Xid 140
incident (reboot pending). See Handoff-vGPU-IO.md ADDENDUM 48.
|
| |
|
|
|
|
|
|
|
|
|
| |
fallback
- UPDATE_PDE_2 now also installs the GR context window PT pages (PDE 17+).
- The shared-path fallback promotes PATCH then MAIN PA-only (mode-13 order,
the real client's set); the mapped (bNonmapped=0) entry still hits the
known 0x40 structural gate and is not sent.
- Shared+srvctx: channel/BIND/schedule/token/GPFIFO fetch all green; the
remaining failure is ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW (0x2c).
|
| |
|
|
| |
GPGet=1, ctxsw fault 0x2c; 10 clean no-wedge cycles; GR fixes committed)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- DMA_UPDATE_PDE_2 client control installs the ladder leaf PT through the
server's own MMU walker on the shared-management VAS (the raw-PDB entries
are not preserved by the root migration); FLUSH_PDE_CACHE + post-install
refill + PT diagnostics.
- srvctx registry profile also disables split VAS management; MAP_MEMORY_DMA
is not served by GSP-RM for this client (NV_ERR_INVALID_FUNCTION), so the
PDE control replaces it.
- shared-path context commit helper: GPU_INITIALIZE_CTX + PA-only
GPU_PROMOTE_CTX for the server-reported (or client fallback) MAIN buffer;
GR_GET_CTX_BUFFER_INFO sends bufferCount=64.
- Result: shared VAS + srvctx no longer wedges; channel/BIND/schedule/token
green, PBDMA fetches the GPFIFO (GPGet=1); remaining wall is
ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW (0x2c).
|
| | |
|
| |
|
|
| |
committed experiment e7ff3bf7)
|
| |
|
|
| |
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.
|