| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
call
|
| |
|
|
| |
validation
|
| | |
|
| | |
|
| |
|
|
| |
callback)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Run #7 proved the membar-WAR descriptor lookup succeeds in the guest
(remap (7,5)->(7,0)); FUN_00e21850 then returns 1. bpz8 breaks after its
two inner calls (FUN_003e99d0 image create, FUN_003dfae0 image load) to name
which one fails.
|
| |
|
|
|
|
|
|
| |
Host oracle (real TU104, 570.211): FUN_0035a4d0(0x13,7,5) succeeds because
the 3-entry remap table at 0x3dc5b80 maps (7,5)->(7,0); the guest has the
same table. bpz7 breaks before/after the lookup and the FUN_00e21850 ucode
load in FUN_005d7e70 to see which one fails in the guest. Also fix invd.py's
lookup address (0x25a4d0, not 0x35a4d0).
|
| |
|
|
|
|
|
|
|
| |
Run #5 named the failing hook: idx=3 FUN_005d7e70 ('membar_war_bug2022401')
returned 999; its only source is FUN_0035a4d0(0x13, dev+0xc50, dev+0xc54)
returning NULL or the ucode load failing. bpz6 reads the live device state
arch/impl at the failure and evaluates the lookup in-process, scanning
(arch,rev) pairs to show which WAR-ucode descriptors exist; invd.py is the
standalone same-probe for a parked cdt.
|
| |
|
|
|
|
|
| |
Run #4 identified the +0x4580 target as file 0x4d1fa0: it runs four
descriptors 0x440f780/7c0/800/840 whose fns are 0x4d9350, 0x4c8a70,
0x4ad980, 0x4d7e70 and returns the first non-zero status. bpz5 breaks on
the hook call/return and prints the failing index, target and status.
|
| |
|
|
|
|
|
| |
Run #3 named the failing store: file 0x275cec, the indirect call at
0x275ce6 (slot +0x4580 of the table at [ctx+0x40], called with
(ctx, obj+0xb8)) returned 0x3e7. bpz4 prints the runtime target pointer so
it maps to the architecture vtable implementation that failed.
|
| |
|
|
|
|
|
| |
Run #2: all post-pump call sites up to 0x2755bf returned 0, but FUN_00374240
returned r14d=0x3e7 (999) 554 ms later. bpz3 arms every mov %eax,%r14d store
in FUN_00374240 plus the alternate epilogue and the single direct 999 store,
printing the first non-zero status with a backtrace.
|
| |
|
|
|
|
|
|
| |
bpz.py probes the four known rc=999 stores on the cuCtxCreate path plus the
scanner force sites; the live run eliminated all of them and showed the
engine event pump (FUN_0031a3b0) returning success. bpz2.py probes every
post-pump status store in the ctx bring-up (FUN_00374240) and the function's
final return, printing the first non-zero status with a backtrace.
|
| |
|
|
| |
UVM wait)
|
| |
|
|
| |
failure-instant trace)
|
| |
|
|
| |
(all 20 channel releases now land), queue payloads that arrive before the slot pin
|
| |
|
|
| |
watcher reaping, wider CE stream window
|
| |
|
|
|
|
|
| |
gdb_now.sh attaches once at a host-chosen moment (final RM control) and dumps
all threads; oneshot_gdb.sh triggers on user-running state; state_log.sh
records state/syscall/wchan so kernel busy-waits can be told apart from real
userspace spins.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The client's UVM_REGISTER_GPU blocks in uvm_push_end_and_wait on the first
CE channel's tracking semaphore (pool word 0x121000000) waiting for value 3.
The pool payload stayed at 1 while the client pushed: the pump processed
entries whose push bytes were unreadable or had no decodable release, so the
release bookkeeping advanced (expected_sem_payload) but nothing was written
to the pool page.
Treat the GPU semantics as normative: each consumed GPFIFO entry on an engine
channel releases the channel's tracking semaphore with the incrementing
queued value. When the decoded stream carries no release and sema_fake_rel is
enabled, deliver the expected payload through svc_fake_release() instead of
only bumping the counter. Also initialize expected_sem_payload for a fresh
pool page whose current payload is 0 (expected = 1) so the first push is
deliverable from the start.
|
| |
|
|
| |
guest-agent starvation)
|
| |
|
|
|
|
|
| |
- registration wait named and unblocked (first CE channel tracker, value 3;
early push-buffer pinning)
- frontier now the post-registration window (external allocation burst)
- note the recovered guest wedge on the fastest-pin configuration
|
| |
|
|
| |
vmrestart reaps stale watchers
|
| |
|
|
|
|
| |
The client's spin floods the default ring with uvmt/uvsv events; a one-shot
uvbp event was overwritten before the pin scanner read it (push-buffer pin
landed ~50 s after the client began pushing). 64 MB ring + clear.
|
| |
|
|
|
|
|
|
|
|
| |
The first CE channel's push-buffer was only pinned ~1 minute after the
client's failure: uvbp fired at t+4s but semfix's trace read (guest agent,
every 5 loops) picked it up at t+70s, so the tracker wait for value 3 spun
for 16 s. The guest scanner now emits '#pb 0x<kptr>' from the uvbp trace
lines as soon as they appear; the host mirrors them into the sem stream and
semfix resolves/pins the push-buffer through the UVM chain on the next loop
(sub-second).
|
| |
|
|
|
|
| |
uvsv/uvsvr capture (sem, value) and the boolean return of
uvm_gpu_tracking_semaphore_is_value_completed, so a wait that fails despite
an advanced payload is visible as a false return.
|
| |
|
|
|
|
|
|
|
|
| |
The failing wait (uvtw) is uvm_tracker_wait_for_entry for value 3 on a CE
channel whose tracking sem stayed at payload 1 for 14 s: its pushes'
release values 2..3 were never applied because the CE push-buffer pages
(0x120000000 + 0x100000*rank) are outside the GR window and were only
found by the content sweep, late and often wrong (false=3065). Scan both
windows in the guest so the host gets guest-truth translations for the CE
pushes as well.
|
| |
|
|
|
|
| |
The failing wait is uvm_tracker_wait_for_entry inside channel_pool_add
(UVM_GPU_REGISTER): capture the tracker entry's channel pointer and value so
the host can tell which release value is still missing.
|
| |
|
|
|
|
| |
The failing wait can live in a libcuda worker thread (strace without -f
misses it); sample every /proc/<pid>/task/*/stack + wchan while the client
runs.
|
| |
|
|
|
|
|
|
|
|
|
| |
- docs reader with rendered Markdown and a built-in Mermaid renderer
(flowchart TB/LR with subgraphs, stateDiagram-v2, sequenceDiagram)
- syntax-highlighted code viewer with per-file added-line highlighting
- foldable file tree; search via git grep
- history: browse docs/code at any commit or branch without checkout
- architecture explorer: zoom whole system -> module -> components, with
calls-into and source-file jump
- strictly read-only; non-interactive modes (--render/--diagrams/--tree/--log)
|
| |
|
|
|
|
|
|
|
|
|
| |
- the trace tail (subprocess + 256KB read) ran inside the scan loop and
blocked it for seconds exactly when the client's GR window appeared;
moved to a background thread whose queue the loop drains.
- scan interval 250ms -> 100ms.
- track_waits sampler also dumps 512 raw bytes at page+0xe00 each sample:
the per-slot reads disagreed with the bulk dump within one sample
because host writes land between the two, and the raw dump is the only
trustworthy view of the slot layout.
|
| |
|
|
|
|
|
| |
The injection queue was only drained at the top of the service loop, which
can be inside a multi-second pump/discovery pass; live runs showed the GR
counter pins landing ~1 s after the client mapped the page, i.e. after its
context-init deadline. Waking on enqueue drains the batch immediately.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
through the exact slot
Live evidence: with the counter page pinned, counter_pa still resolved to a
stale self-discovered page, so every release write went to memory the client
never polls (host read back its own 1s; client's page stayed 0) and the
client's context-init wait expired. The generic release path could also write
through that stale translation.
- svc_counter_autoreg / svc_counter_learn trust only the injected-pin table
(svc_ipin_lookup); learn re-registers when the injected PA differs.
- Releases whose target is in the GR counter VA range skip the generic
translation write entirely and go through the injected-pin-backed slot.
|
| |
|
|
|
|
|
|
|
|
|
| |
counter-page delta
- rel-apply/publish now log the first 32/48 outcomes (written, skipped with
current value, no slot, read failure) so the live counter page can be
matched against host writes.
- guest pin scanner logs the counter page's pagemap state each loop and adds
it to the delta set explicitly, so the page is pinned the moment it is
mapped even if the window scan misses it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fake-release fallback acknowledged unreadable CE pushes even when the
tracking-semaphore pool page had no translation yet, so the GPFIFO entry was
consumed without writing the semaphore the client waits on (observed: client
stuck in UVM_GPU_REGISTER while CE channel 2's release never landed, its
push-buffer pin arriving ~2 s later).
- svc_fake_release now reports failure when the pool page cannot be
translated/read/written instead of pretending success.
- CE channels with the fallback enabled leave the entry pending (no
multi-second RAM rescue) until the pool pin lands; the skip path only
consumes an entry when the release was actually delivered.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
queue 4k
- counter_pa autoreg result is written back to the channel table so later
passes cannot re-target a different slot when the live GR count changes
during teardown; re-registration of the same channel preserves the slot.
- counter slot layout uses the max GR count ever seen in the generation
instead of the shrinking live count.
- sema_map_add queue 64 -> 4096 entries so a full-window pin burst drains
without ENOSPC retries.
- pin_gr_stream: one batched sudo pass per flush (was one process per run,
~4 s for 400 runs), retrying only queue-rejected runs.
- semfix_uvmt: SEMFIX_SKIP_PB=1 skips the blocking push-buffer chain walk
when the vsock window stream already supplies those pages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- new 03-architecture/09-full-system-picture.md: end-state map, GSP boot,
guest init, RPC lifecycle, memory model, work path (bridge and end state),
scheduling, isolation levels, KVM/mdev/VFIO, BAR/engine/channel/GMMU,
portability, performance model, implementation/test status
- new 03-architecture/10-interaction-and-scheduling.md: interaction inventory,
control-plane call path, msgq element lifecycle, channel pump, concurrency,
timing budgets, multi-tenant scheduling, teardown ordering, versioning
- README: mermaid system diagram replaces the ASCII block; reading list
extended and renumbered
- component docs: GSP boot sequence, mdev/VFIO lifecycle, end-state
interaction sequence; STATE-CURRENT links
|
| | |
|
| | |
|
| |
|
|
| |
puts)
|
| |
|
|
| |
GR GPFIFO rings)
|
| |
|
|
| |
memsets)
|
| | |
|
