| Commit message (Collapse) | Author | Age |
| | |
|
| | |
|
| |
|
|
| |
--boot is the only device-writing mode (full boot lifecycle: FWSEC, Booter Load, RISC-V start, FALCON_OS, RM-init poll). --boot-dryrun rehearses the host staging read-only. --keep leaves a green claimed session running. --fwsec is retired and refused at parse time: a FWSEC-only carve is not host-recoverable on this part.
|
| |
|
|
|
|
|
|
| |
Stage 3d stages the GSP-RM boot from host sysmem (FMC, radix3 over the GSP-RM ELF, signature, message queues, libos LOGINIT/LOGRM/RMARGS and GSP arguments) and runs Booter Load on SEC2: GSP RISC-V reset, libos mailbox, IMEM/DMEM direct load, BOOTVEC=0, M0==0, FALCON_OS, RISC-V active. Stage 3e links the status queue and polls for GSP-RM events; it now also executes the inline run-sequencer command buffer (event 0x1002) against BAR0 (REG_WRITE/MODIFY/POLL, DELAY, STORE, CORE_* including CORE_RESUME) and then waits for GSP_INIT_DONE 0x1001.
Gated by gsp_phys_boot / gsp_phys_boot_dryrun (default off; the normal load path writes nothing). gsp_phys_fwsec=1 without gsp_phys_boot=1 is refused: a FWSEC-only carve cannot pass the booter-unload handoff gate. Release quiesces the GSP, runs the existing FWSEC-SB/booter-unload teardown and frees all staging.
tools/gen_gsp_bindata.py decodes the public generated archives into the Booter Load image (prod signature patched at 0x8700) and the GSP-RM boot (FMC) image; both are self-checked at build time.
|
| | |
|
| | |
|
| |
|
|
| |
abort checks)
|
| |
|
|
|
|
|
|
| |
Reproducible TASK 2 harness: fresh boot, sema_dbg=Y with
sema_copy_dst=0x200000 / sema_copy_dst2=0x208000, cdt2 parked at
CDT_CP_PAUSE so the root PD/PT pages can be dumped and walk_probe run
while the client is live. Prints the offending write data (prov= names
the translation layer) and the post-run walk state.
|
| |
|
|
|
|
|
|
|
| |
The DtoH staging buffer lives in the client's high-VA /dev/zero|nvidia
mappings (e.g. devptr+0x3c00100), outside the scanner's fixed CE/GR
windows; only the host's pagemap read can see it. The guest scanner
now walks those VMAs and streams their present pages so the module
pins them. run_cycle.sh learns the sema_dbg master switch (auto-on
when any watch knob is set).
|
| |
|
|
| |
failure left a boot without pins and the client hung)
|
| |
|
|
|
|
| |
A fresh boot can leave /sys/kernel/tracing as an unmounted mount point;
the probe adds then fail silently (probe count 0) and the whole sem/kptr
pipeline goes blind.
|
| |
|
|
|
|
|
| |
A new CUDA client allocates fresh channel pools at the same GPU VAs; the
watcher kept the previous client's sem kptrs and seen-pin marks, so it
pinned the previous (freed) pool pages and the new client's release writes
went to dead memory. Clear the learned sems/marks on each pid change.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
HMP x/gva2gpa translate with the selected vCPU's CR3; while that CPU runs
user code under PTI the kernel half is hidden, so kernel-VA reads (the
tracking-sem chain and the CE pushbuffer CPU alias) fail and the pin pass
aborts. Try the other vCPUs before giving up: during an active CUDA client
at least one CPU is in kernel mode, so the chain/pin work no longer require
the client to be parked in sleep().
|
| | |
|
| |
|
|
| |
can block)
|
| |
|
|
| |
SIGBUS on truncated file maps)
|
| |
|
|
| |
mechanism probe)
|
| |
|
|
|
|
|
| |
The GR-window pin scanner matched comm=="cdt" exactly, so runs using the
cuda_drv_test2 binary (comm "cdt2") never streamed their mappings: the
GR push pages stayed unresolvable and the client stalled in context
creation. Match the cdt prefix instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 256-byte cuMemcpyHtoD payload never appears in any CE push: CUDA
submits it on the compute channel as a compute-class DMA whose source is
the push's own inline data (LINE_LENGTH_IN=256, OFFSET_OUT=<device VA>,
LAUNCH_DMA=0x41, LOAD_INLINE_DATA 64 dwords, then the channel's
SET_REPORT_SEMAPHORE release). The CE-shaped decoder skipped the data run
(opcode 3) and no GR work ran at all.
- Decode NVC5C0 GRCE methods on subchannel 1 (LINE_LENGTH_IN, LINE_COUNT,
OFFSET_OUT/UPPER, LAUNCH_DMA) and the opcode-3 LOAD_INLINE_DATA run.
- svc_grce_inline_write resolves the destination VA through trusted
sources (pins, map, published page directories, targeted rm_mem
resolve), pins the page and writes into vidmem or guest RAM; budgeted
sema-grce logs name the target or report UNRESOLVED.
- cdt2 test binary gains CDT_CP_PAUSE / CDT_HP_PAUSE for live inspection
of the copy path; pushed by push_guest_tools.sh.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
payload-pattern audit
- CE LAUNCH_DMA releases are now applied after the push's collected work
runs: the client reads copied data as soon as it observes the release,
so release-first let cuMemcpyDtoH observe a copy that had not executed.
- Unreadable CE entries stay pending for a grace window (sema_ce_grace_ms,
default 8s) before the release fallback consumes them, so a translation
that lands within a service pass lets the push be decoded and its work
executed instead of being dropped.
- sema_copy_pat matches an 8-byte value against every copy's src/dst first
word and scans decoded pushes for it, naming the submission that carries
a known payload regardless of size/encoding.
- sema-dma-skip logs transfer-shaped launches that collect no op; op log
lines carry the channel handle; LAUNCH_DMA inventory follows OPS_LOG.
- A real release application now records the release VA, so decoded pushes
no longer trigger a spurious fake release.
|
| |
|
|
| |
CDT_WAIT passthrough
|
| |
|
|
| |
retries until complete)
|
| | |
|
| |
|
|
| |
run_cycle OPS_LOG knob
|
| |
|
|
| |
window has no CPU alias; the vsock stream cannot supply it)
|
| |
|
|
| |
roundtrip diagnostics
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
| |
failure-instant trace)
|
| |
|
|
| |
(all 20 channel releases now land), queue payloads that arrive before the slot pin
|