summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Revert "vgsp-sema: hold an entry on any unresolvable operand, not only ↵Arthur Hanson Rasmusson3 days
| | | | | | mid-scan (ISSUE-0002)" This reverts commit 61cc7629f989edd216c4381313c07f15ceaf1559.
* vgsp-sema: hold an entry on any unresolvable operand, not only mid-scan ↵open-iov-agent3 days
| | | | | | | | | | | | | | (ISSUE-0002) The guest driver's pma scrub submits vidmem memsets on a GR channel; the operand translations (client buffer VAs, pinned by the scanner) land about a second after the push. The one-pass skip lost those memsets forever and the guest spun in scrubCheckAndWaitForSize (r58 c3: three bigop memsets rc=-22 at 17:54:35, their pins logged at 17:54:36, the channel froze at get=89 with the client in pmaAllocatePages). Mark the operand path pending on any unresolved operand so the existing bounded entry hold retries the decode until the translation lands; raise the retry bound to 160 so the hold covers the observed pin latency.
* vgsp-sema: never seed last_get past a discovery put >= 2 (ISSUE-0002)open-iov-agent3 days
| | | | | | | | | | | | | | | A fresh CE channel can legitimately reach the service's first pass with a live put far above 1: the driver publishes the put once per submitted push ((cpu_put + 1) % entries) and clients stream pushes while the service is still discovering the channel. r56 measured healthy sessions at put=66/134 within seconds; r54's third-session rank2 discovery read p=67, g=67 (a LIVE put), the r48 seeding set last_get=67, and the client's first push (entry 0) was never decoded - the channel_pool_add spin. Always start at slot 0; a genuinely stale block is still handled by the existing put-drop resync. Also make the CE put-snapshot diagnostic per-rank (the channel struct iterated is a local copy, so the old per-channel stamp let the first rank spend the whole session budget) and raise its cap for a third-session rank2 to keep logging through a stall.
* vgsp-sema: software-author the GR launch completion release when the ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | physical forward fails (ISSUE-0002) r51/r52 root evidence: the second session's GR launch was forwarded to the physical engine; the backend timed out (qmd_rel=5 want=6 after 5 s) while the hold resolution applied only the *stream-recorded* channel release. The QMD launch completion semaphore (the word the client polls in its launch- completion wait) is carried by the GR candidate (gr_rel_va/gr_rel_payload), not by the release records, and nothing authored it on failure - the client spun forever in the completion wait and the pump went idle (pushes=1207, pending=499, crel frozen). Fix: - a GR hold waits for the backend's bounded outcome (12 s bound vs the backend's 5 s poll) instead of the 500 ms CE copy bound, so the release is never authored while the physical submission is still writing guest pages; - on hold resolution without a successful hardware copy (timeout, abort, expiry, or a release0 page the backend could not observe), the QMD release is software-applied forward-only (read/compare, absolute payload write) - idempotent against a late engine write and never rewinds the tracker; - a GR capture whose request did not queue (refused/backend busy/hold active) authors the same release inline when the CUDA bridge is disabled (the bridge job owns it otherwise); - new work_guard counter gr_sw_rel names how often the fallback authored a release, and each write logs its va/payload. Validated: c1 GREEN, c2 GREEN in the same VM (r54; CE->GR, mail + VADD STATUS OK). In that run the forward succeeded so gr_sw_rel stayed 0; the timeout branch is the one r52 proved is reachable.
* vgsp-sema: only ALL-ZERO window-guess push reads fall through (ISSUE-0002)Arthur Hanson Rasmusson3 days
| | | | | | | | | r50 regression: requiring method-stream plausibility for the window source rejected valid non-method push prefixes and corrupted c1 (VADD bad=32767), so that gate is reverted. Narrow it to the r49 failure mode: a window read returning all zeros cannot be a real page (the paired base page is real), so fall through to the learned/discovered resolvers. Non-zero window content is trusted exactly as before.
* vgsp-sema: implausible window-guess push reads fall through to per-page ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | resolvers (ISSUE-0002) r49: the second session's CE push pages beyond the paired base page read all-zero through the linear window guess; because the window read 'succeeded', the learned/discovered/targeted resolvers (src=3) were never tried and every follow-up push was held as unreadable (crel frozen, client spinning). A valid push's first chunk always parses as a method stream, so require that for the window source on the first chunk only and fall through otherwise. Correct window reads are unaffected.
* vgsp-sema: resync a CE channel past residual USERD state on counter reset ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | (ISSUE-0002) r48: the layout USERD of the second session's rank0 was accepted with the previous session's residual PUT=134; the pump consumed 34 stale slots, then the guest's fresh counter reset PUT to 1 and the pump wrapped: last_get never matched the guest's sequence and the live first push was not processed. The client was later seen pushing 216-byte no-release entries with crel frozen. A fresh channel's first push always publishes PUT<=1 and the client waits for its release before a second push, so a PUT>=2 at discovery is residual: seed last_get past it and resync to slot 0 when the guest's own counter reset drops PUT below put_prev. Clear the wait state once entries are consumed without a reset so later genuine wraps keep the normal wrap path.
* vgsp-sema: CE layout USERD accepts on PUT alone; GET is GPU-owned (ISSUE-0002)Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | r47 guest truth (channel_info walk in the hung second client): every CE channel's GP_PUT/GP_GET GPU VAs are ring+0x2008c / ring+0x20088 and the live rank0 USERD is the layout block at fb 0x90000 (the emulation's offsets were right all along). The coherence gate required g <= p, but the GET word is GPU-owned and holds leftovers (session 2 rank0: PUT=1, GET=136 from the previous session) - so the live block was rejected forever (r44 strict never accepted; r42/r46 latched the stale registered candidate). Accept the CE layout block when the PUT word is plausible; the pump tracks ch->last_get and rewrites GP_GET as it consumes entries.
* vgsp-sema: CE USERD layout-only + deferred FB sweep diag (ISSUE-0002)Arthur Hanson Rasmusson3 days
| | | | | | | | | | | r46 evidence: in a second session the CE rank0 layout probe at ring+0x10000 read a transient incoherent pair (-EINVAL) at discovery and the old candidate list immediately latched the stale registered pool-relative offset (another rank's previous-session USERD, frozen 1/1), hiding every later GP_PUT. For CE channels enforce the ring-derived layout block only, retry until it reads coherent, and never fall back to the registered/neighbour candidates. A bounded (+3s, +33s) FB sweep logs the live put/get block when the layout never becomes coherent.
* Revert "vgsp-sema: CE USERD is layout-only" for now (ISSUE-0002)Arthur Hanson Rasmusson3 days
| | | | | | | | | | r43/r44 showed the strict CE branch never engaged for the second session: no sema-chan/sema-put line for c2's CE channels at all (the layout probe did not accept), so c2 stalled before any USERD was selected. Restore the r42 validated-layout behaviour (c1 green, c2 progresses to the known crel=216 stall) until the layout probe's failure in session 2 is instrumented. The next experiment must log the CE branch's ring-validation and layout-probe rc/p/g per pass.
* vgsp-sema: CE USERD is layout-only; never latch the registered stale block ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | (ISSUE-0002) The pump calls svc_chan_userd before the ring is pinned; the old candidate list then accepted the registered pool-relative userdMem offset (stale cross-session 1/1) and userd_ok froze it for the session (r42 c2 rank0 userd=0xf0000 while the layout block 0x90000 is the one the guest writes). For CE channels: wait for the ring, validate its entry0 (a CE push VA + len), then accept the layout USERD at ring+0x10000 even while idle; anything else returns -ENOENT so the next pass retries. Registered-offset candidates remain for non-CE channels.
* vgsp-sema: validate the CE ring entry0 before trusting the layout USERD ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | (ISSUE-0002) r41 c1 regressed: svc_lookup answered rank4's fresh gpfifo VA with an unrelated FB offset (0x90000) and the idle acceptance cemented the wrong USERD (ring+0x10000 of the bogus base). Gate the layout-derived USERD on the ring's entry0 decoding to a CE push VA + plausible len, the same check svc_ring_autopin already uses; a bogus ring now falls through to the previous candidate list.
* vgsp-sema+guest-diag: fix CE USERD discovery for re-registered sessions ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | (ISSUE-0002) svc_chan_userd now prefers the layout-derived CE USERD (ring_pa + 0x10000 in the ring aperture) and accepts it while idle, so a second session cannot latch onto the registered pool-relative offset when that alias holds a DIFFERENT rank's stale USERD: r40 c2 rank0 read rank3's stale 1/1 at FB 0xf0000 and the pump never followed rank0's own GP_PUT (guest GPUT mapping for gpFifoGpuVa proves ring+0x10000). guest_pin_stream.va_to_pa drops translations outside the registered guest-RAM windows so BAR1-phys addresses (0x70000xxxxx) are no longer injected as SYS pins; r40 rank2's ring resolved to the bogus pa=0x70000c0000 ap=SYS and read 66/66.
* guest-diag: accept both GPFIFO ring windows and validate channel_info for ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | #put (ISSUE-0002 diag) CE channels register gpfifo=0x121010000+0x30000*rank, outside the GR-only window [0x200200000,0x200400000) the #put resolver searched, so no #put line ever fired for the CE channels the second session stalls on. Resolve channel_info from both windows with layout validation, keep re-resolving the channel after the pool mem has resolved, reset the #put map on client switch, and add bounded resolver diagnostics to the guest log.
* guest-diag: stream channel CPU-side GPUT on change (#put lines, ISSUE-0002 diag)Arthur Hanson Rasmusson3 days
|
* vgsp-sema: per-second GP_PUT snapshots for CE channels (ISSUE-0002 diag)Arthur Hanson Rasmusson3 days
|
* vgsp-sema: per-session entry-outcome and stream probes for the CE->GR ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | transition (ISSUE-0002) r31 experiment: log every CE GPFIFO entry read (budget raised, reset per session), every svc_decode_stream call, and the two exits that consume an entry without a decoded release (norel hold / unread slow path). Names the exact exit taken by the second session's follow-up pushes.
* vgsp-sema: fall back to the displaced injected pair for push reads (ISSUE-0002)Arthur Hanson Rasmusson3 days
| | | | | | | | | | The conflicting-injection race handled for pool releases also poisons push pages: when the later store wins the pin table, the pump reads a page the client never wrote, the push fails the method-stream plausibility check and its releases never decode. When the primary read is implausible (or unreadable through every source), try the recorded displaced translation once before the rescue/hold paths; content plausibility stays the arbiter. Bounded sema-pushalt evidence lines (32/session).
* vgsp-sema: free the release-apply budget and re-arm the push decode budget ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | per session (ISSUE-0002) The ipin store/lookup probes served their purpose (the displaced-pin race is understood and handled); keeping them consumed the shared per-session counter_rel_dbg budget before the release path could log, which left r25's second-client stall blind. Remove them and reset svc.entry_log in the session flush so the next session's sema-push decode lines are visible.
* vgsp-sema: keep displaced injected pins and fan pool releases out to them ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | (ISSUE-0002) Two host tools can inject conflicting PAs for the same pool-semaphore VA page; the pin table is one entry per page, so the later store won and the release written through the loser was invisible while the client polled the winner forever (observed r22/r24: fresh va=0x121000000 -> pa matched the client pagemap; a later stale pair overwrote it, the single release write landed on the stale page, and the second client spun in UVM registration). Remember the displaced pair and write the release to it as well: forward-only and read-back proven, best effort, sequential clients only (documented in the helper).
* vgsp-sema: bust the verified pool cache on every fresh injection + ipin ↵Arthur Hanson Rasmusson3 days
| | | | store/lookup probes (ISSUE-0002)
* vgsp-sema: defer pool releases decoded before the guest base/injection lands ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | (ISSUE-0002) Hold pool-VA releases for 5s after a channel registration so the fresh session injection supersedes the previous client's translation, defer a readable-zero pool word instead of absorbing the write, and keep an INC pending entry alive until the word is non-zero. Second-session releases still resolved to the previous client's page (observed: write to 0x122090000 while the fresh injection at 0x134590000 stayed zero) - the stale-pin source is the remaining lead; diagnostic pool-rel candidates added.
* vgsp-sema: never drop a decoded pool release in the counter path (ISSUE-0002)Arthur Hanson Rasmusson3 days
| | | | | | | | | | A CE (pool) release that reaches svc_counter_release_apply finds no counter slot and was discarded. The launch path normally writes pool releases via svc_sem_write, but skips it whenever it believes the value was already applied (or the word was unreadable at decode time); the second session's early releases were lost exactly there. Apply forward-only absolute through the pool writer instead - idempotent for a monotonic tracker, so a duplicate can never double-count.
* vgsp-sema: hoist the GR-ring discovery bitmap declaration for the session flushArthur Hanson Rasmusson3 days
|
* vgsp-sema: re-arm push-buffer and GR-ring discovery with the session ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | (ISSUE-0002) The push-buffer pairing bitmap (svc_pb_done), its pass budgets (svc_pb_passes/svc_pb_idle/svc_pb_last*) and the GR ring bitmap (svc_gr_ring_done) are boot-scoped, but svc_session_flush() only wiped the pins they stood for. The next client reuses the same CE/GR ranks, so discovery skipped every rank, its push pages could never be paired, and its decoded releases were dropped ('no slot registered'): the guest waited on a tracking semaphore that could never advance - the second-client hang. Re-arm the discovery state in the flush.
* vgsp-sema: re-arm diagnostic budgets per session and log the release-apply ↵Arthur Hanson Rasmusson3 days
| | | | silent exits (ISSUE-0002 diagnosis)
* vgsp-sema: log release writes into the UVM sysmem semaphore range ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | (ISSUE-0002 diagnosis) Bounded instrumentation: every svc_sem_write into 0x7924_xxxx_xxxx..0x7926 records (h, va, pa, aperture, resolver provenance, value, write rc, read-back ok/value, pool) so the second session's translations for the same VAs can be compared against the first session's. The second client spins in uvm_gpu_retain_by_uuid -> uvm_page_tree_init -> uvm_push_end_and_wait -> wait_for_entry_with_spin (guest kernel stack, sysrq-l) waiting on the channel tracking semaphore; these lines will name the PA the release landed at.
* vgsp-sema: flush host-injected pins with the session (ISSUE-0002)Arthur Hanson Rasmusson3 days
| | | | | | | | | | The pin-stream tool follows the live client's pid, but its injected entries survived the session flush. The next client reuses the same VAs with new PAs, so stale injections resolved it through the previous client's pages - the second-client exit hang. The 10/10 gate never ran the stream (green); the handover harness does, which is why r3-r10 saw the hang. The queue is drained on svc_thread (svc_handle_map_add), the same thread as this flush, so the clear cannot race it.
* vgsp-sema: synchronize the session flush with channel registration; stop ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | | | | | | sleeping in the VA-space walker (ISSUE-0002) Two host-side defects from the r9 capture: 1. The session-end flush was executed at the top of svc_rebuild without checking whether the next session had already started registering: in r9 it ran between the second client's first and later channel registrations and wiped its freshly learned state mid-setup. The flush now runs on svc_thread only (the sole writer of the discovery state), at the top of its loop; a first channel of a new session waits on svc_sess_flush_done before registering, so the wipe can never land after that session's state exists and the new session still starts from a clean slate. Scans abort on the pending flag so the wait is bounded, and channel_del wakes svc_thread so the flush runs promptly instead of waiting out a pass. 2. svc_walk_vaspaces held svc.vas_lock (spinlock) across svc_gmmu_walk, whose guest reads go through vfio_dma_rw (mutex, may sleep) - the 'BUG: scheduling while atomic' in the r9 service log. The walker now snapshots the published VA spaces under the lock and walks unlocked.
* vgsp-sema: include the learned pin table, counter-derived cache and hot map ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | in the session flush (ISSUE-0002) The second client still resolved through the first client's pages because three session-scoped tables survive svc_session_flush: svc.pin (the primary learned VA->PA table, consulted before every other source), svc_cnt_der (serves a cached PA without re-proving it) and svc_hot (scan bitmap). Clear all three with the rest; svc.ipin is left alone (injected pins are the external pin tool's domain).
* vgsp-sema: only a real session end may request the discovery flush (ISSUE-0002)Arthur Hanson Rasmusson3 days
| | | | | | | | | | | A redundant channel delete (a FREE for a handle that never registered, or a repeated delete after the session already ended) found the channel set empty while the next client was already starting and re-armed the flush, which then executed mid-startup and wiped that client's discovery state (and dropped its pending releases): the client spun at its first channel. Track whether a session's channel has registered since the last flush and request the flush only on the true existed->empty transition; redundant deletes are inert.
* vgsp-sema: flush per-session discovery state when the last channel closes ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | (ISSUE-0002) A second CUDA client in the same guest runs in a new UVM VA space that reuses the same VAs backed by new pages. The service's discovery state (merged scan map, pinned push-buffer pairs, discovered page-directory latch, direct_base, pool-PA cache, CE ring-done ranks, retry queue, forward-release records, GRCE dst ring records, pending releases, VA spaces) is learned from the live client and was never reset, so the next session inherited translations for the previous session's pages: its rings never auto-pinned, releases queued unresolved in svc_pending and the client spun at its first channel. One clean boot always works, so make the next session look like one: when the channel set empties mark a flush; the next rebuild (forced immediately) resets the same state a fresh boot starts with, and the new client re-discovers from its own content.
* vgsp-sema: reject identity pool-semaphore translations (the wedge class)Arthur Hanson Rasmusson4 days
| | | | | | | | | | | Wedges (WEDGE-COMPARE-r7-vs-r10.md) wrote the pool completion to pa==va (0x121000000, src=trusted) instead of the guest's real page (greens use src=pin); the read-back proof cannot catch identity because the SYS aperture reads/writes accept any address, so it cached and the guest's first tracker wait never woke (kernel logging stops at client init, guest wedges). Never accept or cache a pool VA->PA resolved to an identity page: guard lookup/cache/store and every resolver source; a rejected identity misses, so the release queues in svc_pending[] until the real pin lands.
* debug/issue: ISSUE-0001 resolution update - m143 BAR1 root cause fixed; 9/10 ↵Arthur Hanson Rasmusson4 days
| | | | gate with rep10-r10 wedge analysis recorded
* vgsp: restore reproducible green CUDA (ISSUE-0001) - BAR1 exposure, walk-pin ↵Arthur Hanson Rasmusson4 days
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | and publish fixes - Revert m143's BAR1 exposure: report the physical aperture size (256MB) again. Every post-m143 build reported BAR1=512MB and stalled the guest in its first cudaMalloc; the m140 green reference reported 256MB. barprobe-r2 (this tree) is green: VADD n=32768 bad=0, STATUS OK ~10s. - Revert the FORENSICS-grv6-ring walk-authoritative GR ring pin (fix A): it gated the guest's GR pushes on every boot since (no-push class). - Restore the end-of-pass GR counter publish with the pass-computed put (m140 behavior); the H3-only early publish read put=0 from the USERD. Probe branch: probe/no-walkpin (b1694f6a, 82404ad9, a766cc1b).
| * vgsp: PROBE - expose physical BAR1 size again (m143 exposure correlates with ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | | | | | the cudaMalloc spin) Every build since m143 reports BAR1=512MB to the guest and stalls the client inside its first cudaMalloc; the m140 green reference reported BAR1=256MB with the same 512 MiB shadow. Revert to the physical aperture size as the single-variable probe for ISSUE-0001.
| * vgsp-sema: publish GR channels at end-of-pass again (regression fix for the ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | | | | | | | | | | | | | cudaMalloc spin) m140 published every channel with the pass-computed put and GR clients advanced (green counter publish val=put). The H3 change restricted the end-of-pass site to CE and moved GR to the safety-net early call, which reads GP_PUT from the snapshot USERD and returned 0 on live GR channels while the pass's own put was 1. GR never published; victory_mail spun at 100% CPU in the first cudaMalloc (wchan=0). Publish GR here again; the early call remains the fallback for early-continue passes and both are monotonic.
| * Revert "vgsp-sema: walk-authoritative GR ring pin when content not yet ↵Arthur Hanson Rasmusson4 days
|/ | | | | | readable; walk-verdict telemetry (FORENSICS-grv6-ring fix A)" This reverts commit d246c02500a6eb41f88e7aae1febb6e800668d73.
* vgsp-sema: split release slot from completion counter (F1, SA-COUNTER ↵Arthur Hanson Rasmusson4 days
| | | | FORENSICS-grv7-counter): release targets the learned release VA, publish targets the ascending counter slot
* vgsp-sema: remove pub-mirror (guest-perturbing; SA-GATE ↵Arthur Hanson Rasmusson4 days
| | | | FORENSICS-grv7-gate); keep read-only dbg telemetry
* vgsp-sema: walk-authoritative GR ring pin when content not yet readable; ↵Arthur Hanson Rasmusson4 days
| | | | walk-verdict telemetry (FORENSICS-grv6-ring fix A)
* docs(review): fix GMMU-doc anchors and vEP vocabulary; index docs 13/14 in ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | the READMEs The GMMU doc cited pre-c33f6006 lines for the pump, doorbell and svc_sem_write, defined vEP differently from doc 13 (which it names as the vocabulary authority), and called Design A prototypable in the 1.0 programme while M6 classifies the same prototype as post-1.0 research. Fix all three, refresh the status hash, and add the doc to the docs/ and wiki/ indexes with the renumbered reading-order rows.
* docs(review): refresh vEP citations against merged master and reconcile GR ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | | completion with FORENSICS-grv5 Line anchors drifted when c33f6006 landed after the doc was written at d0213b5a (svc_thread, svc_gr_request, svc_pending_add, the H3 guard, the readiness gate). Also: the grv5 SEMA_DBG=Y campaign showed the notifier and event wake-up do fire while the counter slot publication is the link that never writes, so the document's 'completion wake-up' framing was stale in the stage table, section 3.4, section 6.1, the challenges and the iteration plan; refresh the status hash, the discovery-cadence wording and the mode-matrix source note, and extend the change log.
*-. Merge branches 'docs/vexecution-plane' and 'docs/multi-tenant-gmmu'Arthur Hanson Rasmusson4 days
|\ \
| | * docs(multi-tenant-gmmu): multi-mdev isolation design, GMMU tenant/agent ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | paged-attention protection, VRAM oversubscription, portability and M1-M8 roadmap (wiki summary; local provenance in adjacent LOCAL notes)
| * | docs(vexecution-plane): add the vGSP Execution Plane architecture doc, wiki ↵Arthur Hanson Rasmusson4 days
| |/ | | | | | | deep dive and indexes
* / vgsp-sema: debug-gated GR counter mirror + pub-info + GP_GET readback ↵Arthur Hanson Rasmusson4 days
|/ | | | (FORENSICS-grv5 E1/E2)
* vgsp-sema: periodic GR discovery re-arm + FB-first fast path (FORENSICS-grv3 R1)Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FORENSICS-grv3: the FB discovery worked for ranks 0..2 (content-discovered + auto-pinned ap=2, ring_auto 6->9, gpfifo done 89->110, gr_rel 0->3), but the guest only ever wrote ring entry0 for those three ranks during the scan window, and the discovery epoch took its 60-pass cap and retired - the re-arm existed only on channel registration - so the remaining ~8 minutes of guest life had no scanning at all (890 "capped" messages, no pass after ~4189). The first pin was also ~3.5 s late because the 6 GiB RAM walk ran before the FB scan. Changes: 1. Periodic re-arm (FORENSICS-grv3 sections 4-5A). Taking the epoch cap no longer retires discovery: the pass count resets, discovery rests SVC_GR_CONTENT_COOLDOWN (30 s) and then starts a fresh epoch for as long as any registered GR channel still lacks a ring. A registration batch still re-arms immediately (and now also clears the cooldown). When every registered GR channel has a ring, discovery stops with a single "discovery idle" log line. Passes stay one per 2 s and the cap/cooldown bounds the scanning duty cycle, so a permanently missing ring cannot hot-loop. 2. FB scan first + fast path (FORENSICS-grv3 section 5A). The emulated-VRAM scan (direct host reads, milliseconds, bounded to SVC_GR_CONTENT_FB_LIMIT at a page stride) now runs before the RAM walk and records ring candidates without requiring a push candidate. Push candidates are kept across passes (the ctx-init pushes are content-stable), so when every ring-carrying rank already has a push the pass pairs right after the FB scan and skips the RAM walk entirely: a late ring submission becomes visible within one 2 s pass instead of after a full re-scan. 3. Descending RAM walk with early exit. The push (release-group) walk now starts at the top of guest RAM - the same reasoning as the CE content rescue: the guest's work allocations live in the high RAM block (grv3 pushes at 0x1028f...0x12df8..., 4.0-4.8 GiB) - and stops as soon as every ring-carrying rank has a push candidate, so the pass ends in about a second instead of a full 6 GiB walk. RAM ring candidates are still recorded here for boots whose ring is not in FB. The pairing gate is unchanged: entry0 exact, the push parses end-to-end, the release group sits at len-20 with this rank's slot and payload 1, and the USERD at ring+0x2000 reads plausibly. Wrong or stale candidates pin nothing. No module parameters were added or changed. Not included (deliberately): the notifier/event completion path from FORENSICS-grv3 section 5B. Section 3 lists it as the leading hypothesis only, never observed live (the relevant logs are debug-gated), and 5B gates it on this change showing the guest posts nothing more; the sema_dbg=Y experiment is the discriminator. No speculative change was made. Evidence: FORENSICS-grv3 sections 0, 4, 5A; 11-hostdmesg-grv3-r1.log 2727-2735 (FB pins), 2820-2823 (cap), 4060-4062 (capped tail); m104 17-host-m104-r1.txt:164-283.
* vgsp-sema: FB-aperture GR ring discovery + per-registration discovery re-arm ↵Arthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (FORENSICS-grv1 R1) FORENSICS-grv1: the grv1 campaign ran the H1 content pass to its 60-pass cap with zero pairs. svc_read() is vfio_dma_rw over guest DMA addresses, so the 4 GiB guest-RAM scan found all eight GR ctx-init push candidates (len 0x2a4) but no page-aligned ring entry0; the ring lives in the emulated vidram aperture (vgpu->bars[1].vaddr), where m104's green ring was FB 0x140000 + R*0x3000. The trusted walk also missed (the ring VAS is unpublished: VAS[0] root empty, VAS[1] has no usable PD0 for the window), and the H3 early publish was a no-op (put=0 from the pool-relative registered USERD at 0xc32000, which reads zeros in FB). Changes (one coherent commit): 1. svc_gr_content_pin() takes the ring's aperture. The ring page and the USERD at ring+0x2000 are read through that aperture; the push page and its release group stay guest RAM (SYS); the hot-page bitmap (guest-PA indexed) is only touched for a SYS ring. FB rings log "content-discovered GR ring ... -> fb 0x...", RAM rings keep "-> pa=... ap=1". The gate is unchanged: entry0 exact (push VA + len), push parses end-to-end, release group exactly at len-20 with this rank's slot and payload 1, USERD readable (active pair or readable idle) - otherwise nothing is pinned. 2. svc_gr_content_discover() scans the emulated VRAM mapping after the RAM pass for every rank that has a RAM push candidate but no guest-RAM ring candidate, at a page stride, bounded to SVC_GR_CONTENT_FB_LIMIT (512 MiB, matching the existing one-shot fbs scan bound), with the same entry0 filters and the plausible-tail check. Candidates pair with the RAM pushes by length (0x2a4) and rank geometry, then go through the same full gate. 3. The 60-pass one-shot cap is now a per-epoch bound that re-arms on channel registration: gsp_sema_service_channel_add() sets svc_gr_content_rearm for GR channels (the guest recreates channels on every context retry), and svc_gr_content_discover() consumes it and resets the epoch pass count. The cap message is ratelimited and names the re-arm condition, so discovery can no longer retire for the boot while the guest is still trying. 4. The registered userdMem base (pool-relative, reads zeros) is superseded by the ring+0x2000 USERD probe through the ring's aperture; this covers the grv1 "probe rc=-11 from the wrong base" case without a separate path. No module parameters added or changed; the accepted recipe is untouched. Evidence: FORENSICS-grv1 sections 0-5, m104 17-host-m104-r1.txt:164/169, 11-hostdmesg-grv1-r1.log:2308/2339-2347/2429-2435/2796. 5. The GR pin-branch "auto-pinned GR ring ..." line now carries ap=%d, so the latch is unambiguous in dmesg (FB=2 for the content-discovered ring).
* merge ws/code-standards: editorconfig/clang-format, userspace style doc, ↵Arthur Hanson Rasmusson4 days
|\ | | | | | | SPDX sweep, conventions (handoff-code-standards.txt)
generated by cgit v1.2.3 (git 2.39.1) at 2026-10-12 11:04:17 +0000