summaryrefslogtreecommitdiffstats
path: root/kernel
Commit message (Collapse)AuthorAge
* vgsp: fix X DMA init + GR backend timeouts (CONT.399)Arthur Hanson Rasmusson6 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | X-DMA-FIX (gsp_sema_service.c): - svc_chan_userd: run the pristine-FB USERD scan when the r496b sweep ran on a resolved-but-unvalidated ring (ring_pa!=0 but no entry decoded), not only when the ring is untranslated. A stale pin/foreign VAS left the channel without a USERD and X's 10 s pushbuffer NOP test timed out ('Failed to initialize DMA'). - svc_fb_userd_pristine_scan: claim-check with (off,off) so a second GR channel is not considered foreign against the first adopter's ring_off=0. - svc_chan_vas_candidate_promote: register the channel's own parked COPY_SERVER_PDES candidate at the pump turn once its GPFIFO entry 0 content-validates, instead of waiting for the 1000 ms age-out. - pump: fall back to svc_channel_owner_vas when hVASpace==0 (driver 'attach to the TSG address space') so the GR client ring resolves. PAIR-SAFE (gsp_phys_booter.c): default sema_gl_pair_close_entry and sema_gl_sph_bind_pair_safe ON. An unclosed BEGIN/END pair made the replayed window raise ILLEGAL_METHOD_IN_BEGIN_END (Class Error 0x2018 EC 0x0d), the FE parked before the release semaphore, and draws timed out (backend_timeout). Diagnostics: CB-DIAG/CB-DIAG2 per-push fixed-CB capture summary. Verified: X direct-rendering green on attempt 1; work_gr backend_timeout=0 (was 6), backend_ok=5-7.
* vgsp: probe the low-aperture GR ring identity, skip GR holes, widen the ↵Arthur Hanson Rasmusson8 hours
| | | | | | | | | | | | | | | | | | | | | pristine-FB scan The GL client's GR kernel ring lives in the RM low aperture (0x4000000..0xfffffff) and is not mapped by any published client VAS, so svc_lookup returns ring_pa=0 and the ring-gated USERD discovery never runs. - svc_pump_channels: for the 0xbeef0000 GR family, prove the ring content with a raw PA==VA read and adopt that identity translation (re-proven every pass so the churning ring VA re-resolves). - ce_fb_scan / svc_gr_ram_userd_scan: treat zero holes as not-a-window for the 0xbeef0000 GR family and accept entry VAs inside the SEMA VA window even outside the +-2 MB ring window. - svc_fb_userd_pristine_scan: raise the pristine-FB cap from 32 MiB to 512 MiB so the 32.5 MiB USERD candidate (0x207fc00) is scanned. These are defensive and do not by themselves dispatch the guest's real GL draws (the ring entry format and the missing default VAS are still open); see handoff CONT.393-CONT.395.
* vgsp: raise the GSP engine event interrupt so guest ISR drains events and ↵Arthur Hanson Rasmusson17 hours
| | | | | | | | | | | | | | | | | | | | | | | wakes poll() waiters The emulated GSP only signalled the MSI-X eventfd when it queued a status record. The guest's primary ISR (nvidia_isr) decides pending from the CPU_INTR leaf registers, which we never set for the GSP stall vector, so it returned IRQ_NONE: IRQ 33 counted thousands of interrupts while the nvidia event thread sat idle and a client blocked in poll() on /dev/nvidia0 (a GLX swap) waited forever even though the event was already in the status queue. Mirror what a real GSP-RM does when it queues an event: - program RISC-V IRQMASK/IRQDEST for SWGEN0 (read-only to the guest; the GSP firmware owns them), - set SWGEN0 in the falcon IRQSTAT, - latch GSP stall vector 155 in the CPU interrupt tree (LEAF[4] bit 27, UVM_SHARED subtree 2 -> TOP[0] bit 2), - signal MSI-X. Raise it only for POST_EVENT records (replies are polled by the client). Verified on r1680: the guest now writes IRQSCLR SWGEN0, kgspService_TU102 drains events, and glxgears renders (was a hard hang).
* vgsp: complete the X DDX's push-buffer notifications and class-aware display armArthur Hanson Rasmusson17 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Four fixes, built and validated on fresh boots (r1675/r1677): - gsp_display_engine: gsp_disp_update_armed() is class-aware. NVC57D (core) carries the NOTIFY bit (12:12); NVC57E (window) has no NOTIFY bit, so a bound notifier ctxDMA is the arm. Every c57e window flip computed armed=0 before this, so FINISHED and the channel event were never authored and the DDX's composite/flip waits sat out their timeout. - gsp_sema_service: complete the bfef family's NvNotification status (0x8000 -> 0) in svc_client_slot_sweep(). The DDX marks the record IN_PROGRESS before a submit and the GPU (or RM) must write it back to 0; the emulation never did. - gsp_sema_service: sema_gl_hold_apply (default 0) applies a decoded GL release forward-only at svc_gl_flush() out: when the draw section is not captured, with a stale-value and 1 MB jump guard. - gsp_sema_service: extend the 0x8000 sweep to the X DDX's own RM channels (h=0x01xxxxxx). pb_armNotifiers() writes 0x8000 at notif+0xe and pb_wait() polls it back to 0; the bfef-only filter skipped these channels, so the 8 s submit wait expired ("WAIT (2, 8, 0x8000, ...)" then "Wait for channel idle timed out") even though the class2d NOTIFY ack had zeroed the same page before the arm. Evidence: r1675 keeps the X alive past the old 212 s crash point with 0 "Caught signal" lines; the DDX's 2D pipeline runs (get word advances), the host decodes live 3D method streams (VP-METHOD ... 0x1618 BEGIN topology) and the release sweep applies thousands.
* vgsp-sema: read a channel's push through the VAS it declaredArthur Hanson Rasmusson20 hours
| | | | | | | | | | Several VA spaces can map the same GPU VA. The push read's learned/pin chain is global over VASes, so the GL client's CE channel 0xcaf00012 (which pushes at 0x120000000) was answered with a zero page from another VAS and every entry was 'unreadable' while the channel's own VAS mapped the real method stream. Try the channel's declared VAS first; fall back to the existing source chain when it has no published directory or the walk misses.
* vgsp-sema: keep the scrubber release alive while the event pump blocksArthur Hanson Rasmusson21 hours
| | | | | | | | | | | | | | | | | | The guest's PMA scrub wait and the host's status-queue pump can deadlock: the X server's scrub wait holds the guest RM lock the status consumer needs, the ring fills, and every critical event post then waits out its full 200 ms ring-full budget. A service pass can take many seconds, so the next pass's scrub step - the only thing that can release the scrub wait - is starved and the guest never makes progress. Run the scrub step from inside the send path's ring-full wait (service thread only), and re-resolve the scrubber's finish/host-sema words on every pass instead of once: the guest re-creates its RM kernel VAS and re-maps the channel buffer under the same GPU VA (observed: gpfifo VA 0x120064000 moved from PA 0x127e6a000 to 0x1122e9000), so a once-only resolution authored a page the guest no longer polled. Prefer the RM kernel VAS (h=0xc) RAM mapping over a client VAS vidmem mapping, and force re-resolution when a scrubber re-registers.
* vgsp-sema: resolve the scrubber's finish words through the GPU page tablesArthur Hanson Rasmusson22 hours
| | | | | | | | | | | | | | | | | | | | | | The guest PMA scrubber's host-side completion (channel buffer + pbSize + entries*8) was resolved through the learned VA->PA pair map first. When the guest reused the scrubber's GPU VA for a new channel buffer, that map still named the previous allocation's page, and the host authored the finish payload there while the guest polled the new page through its kernel VAS (h=0xc). r1667 live proof: walk_probe 0x12006c000 -> only VAS[1] (h=0xc) resolves to PA 0x10812a000 (the page the guest's vmalloc mapping of the channel buffer points at, and the value it polls); the pair map returned 0x10526a000. Writing the finish value to the correct page (via the guest scanner registration) immediately released Xorg from the RM memory-manager wait and the queued GSP status records drained. Changes: - svc_scrub_pass(): resolve hsem/fin through svc_walk_vaspaces() first, fall back to the pair map only when no VAS maps the VA. - Struct svc_scrub gains authored_gen; a new pa_gen (fresh scanner registration or a corrected derivation) forces one authoring pass even when the scrubber's PUT did not advance, so an already-waiting guest is released without a new submission.
* vgsp-disp: only post the channel event on a real FINISHED notifier writeArthur Hanson Rasmusson23 hours
| | | | | | | | | | | | | | | | The UPDATE path posted the channel completion event on every UPDATE, including armed=0 updates where no notifier was written (r1665 journal: armed=0 `-> none` still posts). Those events drive the DDX's NVKMS FLIP_OCCURRED handler (nvidia_drv.so 0xaee70), which reaps the four notifier slots of every layer and has a fixed-point retry when the completed layer does not match the first DPY object's layer; with non-flip updates raising the event, Xorg spun there at 100 %. Gate the post on `wrote` (armed + notifier written + FINISHED). r1666: the 0xaee70 spin is gone from perf; Xorg moved on to a bounded XAA action-list scan (nvidia_drv.so 0x4dc9c0, nvXAAHandleActionList) plus do_vfs_ioctl/schedule, i.e. the server main loop is no longer wedged in the flip reaper.
* vgsp-sema: derive and register the guest scrubber finish-payload wordsArthur Hanson Rasmusson23 hours
| | | | | | | | | | | | | | | | | | | | The X DDX's NV_ESC_RM_VID_HEAP_CONTROL (ioctl 0x4a) allocates scrubbed pages through the guest PMA's CeUtils scrubber channel; it waits on the channel buffer's finish payload (channelWaitForFinishPayload), which the host's svc_scrub_pass was supposed to author but never did because the guest scanner had not registered fin_pa/hsem_pa (pa_ok=0 in every run). The channel buffer is pb + GPFIFO + sema + finish, and the scrubber's GPFIFO VA is pb + pbSize, so the host semaphore is gpfifo_va + entries*8 and the finish payload is that +4. Resolve that VA through the learned map or the VAS walk at the first pass and register the PAs in place (SYS aperture only). r1665: `scrub geometry hsem_va=0x12006c000 fin_va=0x12006c004 -> hsem_pa=0x10f46a000 fin_pa=0x10f46a004`, then `scrub author put=1..11` and the X server left the kernel scrub spin entirely: perf on Xorg is now 100 % in nvidia_drv.so+0xaee70 (a DDX userspace loop, next wall) with no _nv018351rm/_nv015102rm samples.
* vgsp-sema: capture the X DDX kick arm without a USERD and author its completionArthur Hanson Rasmusson24 hours
| | | | | | | | | | | | | | | | The X server's class2d kick channel (bfef0002) has a 2-entry ring at a page end (0x1203cfff0) and an FB userd offset the guest never writes; the pump's USERD-miss path returned before the entry-0 arm decode, so the class2d SET_NOTIFY target was never captured and every kick push had no address. Decode the ring head directly when the USERD is missing (the ring PA still resolves) and author the zeroed NvNotification at the captured target. r1664: the first bfef0002 instance still missed, but the re-registered one adopted its USERD on the PUT step (put 1 -> 2) at pa=0x10fecc000, decoded its pushes at 0x1203c0000 (len 32/64, have_rel=1), and the notify2d writes fire at va=0x12000d0b0. Xorg's spin moved off the control wait (_nv015102rm 66 % -> 0) and now sits in _nv018351rm (30 %); GZDoom still spins in glcore.
* vgsp-sema: discover direct-GL CE userd pages; complete kick slots; ↵Arthur Hanson Rasmusson24 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | post-reboot diagnostics The direct-GL GL client's CE channels (beef0101/0102) declare a pool-relative FB control page (0x244f800 / 0x244f400 in r1656) while their GPFIFO ring is mapped in guest RAM, and their ring publishes from slot 2 (entry 0 stays zero). The entry-0 layout gate could never fire, the BAR0 fallback rejects offsets past its 16 MB shadow, and the GR-only VRAM shape scan never ran for them, so the channels retired with submissions=0 and the client's CE releases were never applied. r1661/r1663 evidence: enabling the VRAM shape scan for the beef CE family (hole-tolerant entry validation, newest-slot required, a GET bounded to one ring) finds the real control page (fb 0xa00000, put=1) and the CE push at 0x40e0000 decodes; beef0101 now retires submissions=1 with its semaphore releases applied. Also: - resolve the non-pool direct-GL semaphore window (0x4000000..0x4300000) through every published VAS translation (the general resolver can name a stale page while the client polls the beef0300 walk page); - author 0xffffffff in the beef channel's 128 kick-slot records (the glcore 570.144 kick wait polls exactly that payload; r1662 writes are visible in the guest page, but this is not yet the X-server wall); - one-shot nonzero-word dump of the beef0100 push (r1663 proved the GR init push's host semaphore is a true 32-bit VA 0x4238000 payload 1 with hi=0 in v1, so that release is correct); - name CE/GR in the VRAM-scan adoption line. Next wall (r1663): the X server spins in _nv015102rm/os_schedule (66 %) and _nv018351rm (30 %) after the GL client's GLX request; GZDoom blocks in _xcb_wait_for_reply. The display UPDATE completion event was posted and re-posted at 12:12:20, so this is the flip/GLX-sync path, not the lost UPDATE event.
* vgsp-sema: scope GR release deferral to the push's own candidate; fan ↵Arthur Hanson Rasmusson26 hours
| | | | | | | | | | | | | | | | | | | | | | | direct-GL completions The GL client's direct-GL init push (beef0100, va=0x4000000) decoded its release (rel=0x4238000 pay=1) but never applied it: svc_fwd_defer_arm() is global over the cross-pass GR candidate ring, so stale unoffered CUDA/RC candidates made any later push "defer" its release. The record was then wiped by the next decode pass (the r824 failure mode) - no sema-sw, pending or deferred line, and the client's fence never advanced. Apply the r824 rule already used by the C56F site to the SET_REPORT_SEMAPHORE and LAUNCH_DMA sites: defer only when the candidate ring entry belongs to this push (push_va match). A release whose push owns no candidate applies inline. Also queue svc_rel_apply_906f() releases on a translation miss instead of dropping them, add a bounded low-VA sema-sw provenance window, and fan direct-GL semaphore completions (0x4000000..0x4300000) through every published VAS translation (the general resolver can name a stale page while the client polls the beef0300 walk page). Evidence: backups/evidence-20261002-victory/r1656 (beef0100 release decoded, never applied) and r1657 (sema-sw va=0x4238000 rb_ok=1 after the fix).
* vgsp-sema: carry/decode the class2d kick notification targetArthur Hanson Rasmusson27 hours
| | | | | | | | | | | | | | | | | | | | | | | | The GL client arms its class2d kick channel with SET_NOTIFY_A/B + NOTIFY in the first GPFIFO entry, then submits short kick pushes (NOTIFY only) that rely on the target staying programmed in the channel context. Two host gaps left the short NOTIFY with no address, so no completion was authored and the client spun in its kick/fence wait: - a same-handle channel re-registration memset() erased notify2d_va even though the guest kept using the target from the previous incarnation; - the pump's walk seed consumes only the newest entries ending at the live PUT, so entry 0 (the arm) could be skipped forever. Preserve notify2d_va across a same-vgpu, same-handle, same-session re-registration; fall back to it in the GL kick executor when the section did not re-arm; decode the skipped head entries (bounded, up to 8) on discovery and from the pump when the kick-family channel still has no target; and name a NOTIFY that arrives with no target instead of dropping it silently. Evidence: backups/evidence-20261002-victory/r1652..r1655 (kick channel 0xbfef0002, short NOTIFY without SET_NOTIFY, walk seed last_get skipping entry 0). Not yet observed clearing the GL client's glcore spin.
* vgsp: retry deferred display completions; escalate the UVM init-slot releaseArthur Hanson Rasmusson27 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Two live walls from the r1649/r1650 windowed-GZDoom runs: 1. Display completion wake-up. All NV01_EVENT registrations carry hSrcResource=0, so gsp_rm_post_channel_event() always takes the shotgun fallback, which skips events posted within the 250 ms hint dedup. When the display UPDATE is the channel's last push, the pump's retry was gated on new work (put != consumed) and never ran, so the X server's flip wait spun in _nv018351rm/os_schedule forever. Add gsp_rm_post_channel_event_force() (bypasses only the hint dedup; the event burst cap and status-ring free-space discipline still apply), a per-channel event_retry_at, and an idle-pass retry every 250 ms that logs "re-posted after deferral". Also move event_burst_at after the cap check so refused retries cannot keep the window fresh. 2. UVM channel init slot. r1651 gdb proved the channel's tracker entry waits for value 2 while the authored pool word reads 1; a manual write of 2 cleared uvm_push_end_and_wait. The channel's control-entry + init pushes are boot-time configuration, so keep the rank slot moving for 10 s after first submission: one attempt per 250 ms per rank, escalating 1->2->3->4 through every published VAS translation. Values beyond that need the real CE push decode. Evidence: backups/evidence-20261002-victory/r1649/ (X spin perf, event journal), r1650/ (re-post lines), r1651/ (tracker entry value=2, manual write clears the spin).
* vgsp-sema: fan pool releases through every published VAS translationArthur Hanson Rasmusson28 hours
| | | | | | | | | | | | | | | | | | | | | r1647 showed the pool semaphore page can move between the RM memdesc, the self-discovered directory and the per-client VAS directories. The first-success walk landed on a stale directory that mapped the pool VA to the old page (0x2600000) while the guest polled the live page (0x126502000): the UVM channel-init tracker read 0 and GZDoom spun in uvm_push_end_and_wait. A manual write to the live page cleared the spin. Add svc_walk_vaspaces_collect(), which walks one VA through every registered VAS and returns the distinct translations, and svc_pool_write_all_vas(), which writes a pool value through each (forward only, read-back proven, identity and unreadable pages skipped, bounded log). Pool releases and the tracker-slot fallback now fan out through the collected translations in addition to the boot primary/secondary candidates. The counter is forward-only, so a duplicate on a stale semaphore page is harmless. Evidence: r1649 (all six UVM channels authored; GZDoom leaves uvm_spin_loop and advances to the GL client path).
* vgsp-sema: author the UVM init-push release at the channel's own rank slotArthur Hanson Rasmusson28 hours
| | | | | | | | | | | | | | | | | | | | | | | | r1645 live proof fixes the channel-pool slot mapping: UVM allocates one tracking semaphore per channel in channel-creation order, so channel rank N owns pool slot N, and channel_init() waits for payload 1 at that slot. The r1642 rank+1 fallback pre-satisfied the next rank before its uvm_gpu_semaphore_alloc() zeroed the slot; the value was lost and the guest spun in uvm_push_end_and_wait (r1644/r1645: manual write of 1 to the rank-1 slot cleared the spin). - pool-tracker apply now targets slot = ce_index and fans the value out to the secondary pool-page candidate, which flaps between the RM memdesc and the guest's VAS walk (r1645: the guest polled the walk page while the boot cache named a stale, reused page). - first-submission authoring no longer requires an unlatched ring. A latch with put=get=0 still needs the release (rank 5, r1646), so every UVM CE pool channel authors its own rank slot once when the work-submit notifier clears; one-shot per rank, forward-only, idempotent. - widen the UVM CE GPFIFO window filter to 0x121800000. Evidence: backups/evidence-20261002-victory/r1645 (channels advanced once the rank slot was written) and r1646 (ranks 0-4 green; rank 5 exposed the latched-but-undecoded gap).
* vgsp-sema: release the UVM channel tracker slot tooArthur Hanson Rasmusson40 hours
| | | | | | | | | | | | r1642 gdbstub proved the guest polls pool map slot 1 while the push releases slot 0: rank-0 UVM channel's uvm_gpu_tracking_semaphore resolves map_base + index*4 (index=1) = 0x121000004 (PA 0x104ea2004), the release decoded from its push targets 0x121000000, and writing the payload into 0x104ea2004 cleared uvm_push_end_and_wait. When a CE channel releases the pool map page, also apply the forward-only value to map_base + 4*(rank+1) through the verified pool resolver (read-back proven), and log pool-tracker-wr.
* vgsp-sema: backfill a promoted pool semaphore pageArthur Hanson Rasmusson41 hours
| | | | | | | | | | | | | | r1640: UVM's channel-pool release was written to the boot-cache page (pa=0x2600000) and 54 ms later a verified VAS walk promoted a different page (pa=0x103ac0000, sysmem) to primary. The value was never carried over, so the guest tracker polling the walk page read 0 and GZDoom spun forever in uvm_channel_manager_create -> uvm_push_end_and_wait -> uvm_spin_loop. On every primary/secondary swap in svc_pool_boot_store(), max-merge the old primary page into the new primary page (semaphore words are forward-only monotonic counters; read both pages first, never write on a read failure, never merge a page into itself) and log pool-merge.
* vgsp-disp: map class 0xc57b to its real control window (window-imm)Arthur Hanson Rasmusson42 hours
| | | | | | | | | | | | | The header labelled 0xc57b CURSOR and mapped it to the cursor-PIO block at 0x6d8000+n*0x1000, but 0xc57b is the immediate-mode window class whose control window is 0x690000+(n+32)*0x1000 = 0x6d0000+n*0x1000 (0xc57a is the PIO cursor channel, valid=0). The engine therefore polled the wrong window for every 0xc57b channel: their PUT was never seen, no UPDATE ever completed, and r1638's GZDoom-triggered mode set left X spinning in an RM ioctl after the window-imm flip. Rename the constants (WINDOW_IMM 0xc57b, CURSOR_PIO 0xc57a) and return the correct control offsets; cursor-PIO keeps 0x6d8000+n*0x1000.
* vgsp-disp: retry a lost UPDATE completion event from the pumpArthur Hanson Rasmusson42 hours
| | | | | | | | | r1636: the X-start mode set wrote FINISHED but the channel completion event was refused (event burst cap / transient status-queue state) and never retried, so NVKMS waited forever and X wedged in os_acquire_rwlock_write. Mark the channel event_pending on a failed post, retry it every pump pass (outside disp.lock), clear on success, and log the failure/recovery plus hObj in the UPDATE line.
* vgsp-disp: scan the BAR3 shadow for the display instance tableArthur Hanson Rasmusson42 hours
| | | | | | | | | r1635 live proof: the 32 MiB RM BAR2 aperture is the 64-bit PCI BAR2/3 pair and is enumerated as resource BAR3 (BAR2 empty), so the instance block lives in bars[3] (block base +0x3000 in the shadow; 0x10013 target=2 base=0x114103000, 0x10075 target=3 base=0x114138000). Scan bars[2] and bars[3] in the resolver and log the bar index; the BAR2-only scan found nothing (0 resolutions).
* vgsp-disp: resolve the display instance table in the guest BAR2 shadowArthur Hanson Rasmusson43 hours
| | | | | | | | | | | | | | | | | | The guest kernel RM builds the 64 KiB display instance block in FB but writes it through the guest's BAR2 virtual aperture (memdescMapInternal -> BAR2 with RMCFG_FEATURE_PLATFORM_GSP=0), while control 0x20800a49 hands only the FB PA to the display engine. The hash table therefore never appears in the FB shadow or guest RAM, which is why the notifier context-DMA handles 0x10013/0x10075 could not be resolved and FINISHED was never written (r1633). - add a BAR2-shadow hash/object-entry search (8-byte entry walk, 4 KiB block-base candidates, target/limit validation) to the resolution chain after FB/shadow/RAM; - fix the hash instance field mask to 11 bits (0x7ff); - carry the object target and route the notifier status through the FB shadow for target 1, guest PA for sysmem targets 2/3; - SET_NOTIFIER_CONTROL.OFFSET is in 16-byte units (was scaled by 4).
* vgsp: bar1_full A/B knob for the display instance-memory mappingArthur Hanson Rasmusson2 days
| | | | | | | | | | | | The guest sees a 256 MiB BAR1 over a 512 MiB FB, so the display instance block at 0x1fff0000 (top of FB) is not directly mappable and the guest's hash-table writes never reach the emulated vidmem shadow (r1633: notifier ctxDMA handles 0x10013/0x10075 unresolvable; not in the shadow, not in guest RAM; 0x20800afa GSP-DMA never sent). bar1_full=1 exposes the whole emulated FB as BAR1 (the m143 behaviour) so the test can settle whether the aperture is the missing link; the default keeps the historical 256 MiB physical aperture (CUDA-safe).
* vgsp-disp: find the instance block by the ctxDMA handle anywhereArthur Hanson Rasmusson2 days
| | | | | | | | | | | | | | | The guest BAR1 is a 256 MB window over a 512 MB FB, so the RM writes vidmem through a shifted BAR1 block and the announced instance PA does not index the shadow (r1632: hash_nz=0 at 0x1fff0000; scan also empty where it looked). Resolve like the hardware does, but empirically: parse the announced block; if the handle is not there, search the FB shadow (then guest RAM for the coherent-mapping case) for the 64 KB block that contains an entry for the ctxDMA handle and _parses_ into a valid object entry; use that block's object entry for PA/limit. Cheap for the 56-per-boot notifier writes: a failed handle is not rescanned for 5 s.
* vgsp-disp: retry the instance block through guest RAM when the shadow copy ↵Arthur Hanson Rasmusson2 days
| | | | | | | | | is empty The RM's vidmem writes may use the coherent CPU mapping rather than the BAR1 aperture, in which case the display instance block lands at the announced address in guest RAM. Log the source used (src=fb|ram) and fall back to vfio_dma_rw before reporting the hash table empty.
* vgsp-disp: never publish GET past PUT; bounded no-parse push dumpArthur Hanson Rasmusson2 days
| | | | | | | | | | | | | | | r1630: the window channel's first push read returned unparseable bytes (0 methods) and the parser walked off the 4 KB ring, publishing GET=0x1000 while PUT stayed 0x4e4. nvidia-modeset then wedged in 'Error while waiting for GPU progress', Xorg never started and glxinfo/ GZDoom never reached the GL path. Only consume a segment that parses exactly to the driver's PUT. On a short/invalid read, leave consumed unchanged: the pump retries next pass (which also covers a ring the guest kicked before its content is visible) and GET can never move past PUT. Dump the head of an unparseable segment (bounded, disp_dbg) to name what the ring holds. Reset dump budgets per mdev cleanup so each boot keeps its diagnostics.
* vgsp-disp: locate where the instance hash table actually landsArthur Hanson Rasmusson2 days
| | | | | | | | The 0x20800a49 announce says vidmem PA 0x1fff0000 but that block reads zero in the function RAM shadow. Bound a one-shot whole-shadow scan for hash-entry-shaped words (word1 = {chn[31:25], instance[24:14], client[13:0]}) and log BAR1_BLOCK (BAR0 0x1704) so the BAR1 aperture shift, if any, becomes visible.
* vgsp-disp: resolve the notifier via the announced display instance memoryArthur Hanson Rasmusson2 days
| | | | | | | | | | | | The guest announces the display instance-memory block (8 KB context-DMA hash table + entries, vidmem PA 0x1fff0000 on r1627) via NV2080_CTRL_CMD_INTERNAL_DISPLAY_WRITE_INST_MEM (0x20800a49), but the engine ignored it and scanned its FB shadow blindly, never finding the hash entry - so SET_NOTIFIER_DMA handle 0x10013 resolved to pa=0 and UPDATE never wrote FINISHED (r1627: UPDATE armed=1 notifier=0x0/0). Handle 0xa49, record pa/size/address space per guest, read the block through the FB shadow (or guest RAM for sysmem), and parse the hash table from the announced location with bounded diagnostics.
* vgsp-rm: report TU104 GR identity in KGR_GET_INFO (SM_VERSION 7.5)Arthur Hanson Rasmusson2 days
| | | | | | | | | | nv3dAllocDevice reads SM_VERSION (GR info index 0x0c) through the 3D library; with the emulated KGR reply leaving it 0 it gets SM_VERSION_NONE, GetSpaVersion fails, nvHsAllocDevice returns FALSE silently and nvidia-drm reports 'Failed to allocate NvKmsKapiDevice' (r1626 gdb: nvHsAllocDevice -> nvHs3dAllocDevice -> nv3dAllocDevice). Fill SM_VERSION=0x705 (7.5) plus MAX_WARPS_PER_SM=64, MAX_THREADS_PER_WARP=32 and THREAD_STACK_SCALING_FACTOR=1.
* vgsp-disp: byte method addresses in the push parser (x4)Arthur Hanson Rasmusson2 days
| | | | | | | | | The NV DMA METHOD_OFFSET field is a dword index; gsp_disp_method() compares against byte offsets (UPDATE 0x200, notifier 0x208/0x20c). The executor compared the raw index (0x82) against 0x200/0x208, so UPDATE and SET_NOTIFIER could never match and the FINISHED write never fired (exposed by the r1625 raw push dumps). Shift the decoded offset to bytes.
* vgsp-disp: bounded raw push dumps; 14-bit method offset decodeArthur Hanson Rasmusson2 days
| | | | | | | | | | disp_dbg now dumps the head and tail of the first four executed push segments - the tail is where the core update completion lives (UPDATE 0x200 / SET_NOTIFIER 0x208/0x20c), and r1624's 16-byte second push carried neither parseable method. The NV DMA method offset field is 15:2 (14 bits), not 13:2; widen the parse mask so higher display method addresses are not truncated.
* vgsp-disp: fix disp.lock self-deadlock; backfill h_object from the allocArthur Hanson Rasmusson3 days
| | | | | | | | | | | | | gsp_disp_engine_channel_add() took disp.lock and then called the self-locking gsp_disp_find_object(), deadlocking the RPC thread on the first display push-buffer control (r1621c: watchdog hard lockups in gsp_emu_0 channel_add+0x13b and gsp-sema-svc pump+0x88, R13=0xc57d). Use a caller-holds-lock helper instead. The push-buffer control arrives before the alloc (control, registration, alloc), so a channel registered from the control had h_object=0 and the completion-event post stayed inert. Backfill h_object when the alloc note lands for a registered channel.
* vgsp-disp: unconditional pushbuffer receipt log + NvBool valid fixArthur Hanson Rasmusson3 days
| | | | | | | | | | | | | Log every NV2080_CTRL_CMD_INTERNAL_DISPLAY_CHANNEL_PUSHBUFFER (0x20800a58) receipt with the decoded 56-byte params struct, and always log rejected channel registrations and SET_NOTIFIER_DMA - boot-only volume, settles whether the kernel RM ever programs the display push buffers through that control (r1621 follow-up). valid is an NvBool (1 byte); the previous u32 load could read the padding bytes and turn a PIO-channel valid=0 into a false positive. Raise the engine log budget to 4096.
* vgsp-disp: host-side EVO display engine (channels, push buffer, notifier, ↵Arthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | | | | | | | | | | | | raster) The guest nvidia-modeset drives the display through per-channel NV-DMA push buffers kicked via the BAR0 UDISP control windows. Emulate that engine contract host-side, unmodified guest: - channel registration: display-channel RM objects (core 0xc57d, window 0xc57e, cursor 0xc57b, 0xc57a) are noted from the alloc stream, and the internal control NV2080_CTRL_CMD_INTERNAL_DISPLAY_CHANNEL_PUSHBUFFER (0x20800a58) records each push buffer (guest PA, size, class, instance, validity); - PUT polling + GET publication in the channel control pages (core 0x680000, window 0x690000+n*0x1000, cursor 0x6D8000+n*0x1000); - NV-DMA method parser (METHOD/ONE_INC/NONINC/JUMP/SET_SUBDEVICE_MASK) with the wrap-JUMP follow; - completion: SET_CONTEXT_DMA_NOTIFIER / SET_NOTIFIER_CONTROL tracking, exact notifier-surface resolution through the display instance hash table (no heuristic writes), NV_DISP_NOTIFIER FINISHED on UPDATE (0x200), and the channel completion event post; - free-running 1080p60 raster line for NVC57E_GET_LINE. All effects are behind independent knobs (disp_engine, disp_finish, disp_vblank, disp_events, disp_notifier_pa) with verbose diagnostics (disp_dbg, disp_dump), so the previous behaviour stays one load away.
* vgsp-rm: report connected DFP-0 + 1920x1080 EDID, accept IMP, route headArthur Hanson Rasmusson3 days
| | | | | | | | | | | | - 0x730108/0x730240/0x73028a: display 0 connected, DFP, 600 MHz pclk - 0x730245 GET_EDID_V2: 128-byte EDID 1.3 (1920x1080@60 + range limits) - 0xc3720101 IMP: echo request + bIsPossible (byte 1904) so EDID modes validate - 0x73010b head routing map: displayMask=1, headRoutingMap=0 (display 0->head 0) - alloc dump limit raised to expose the display channel allocations The guest boot display init still needs the display engine (core notifier + vblank/swap-ready) before the mode set can complete; this is an incremental display-state step, not a boot-fix (evidence: backups/evidence-20261002-victory/r1619/).
* vgsp-rm: pump critical event posts instead of dropping on a full status ringArthur Hanson Rasmusson3 days
| | | | | | | | | | | | | | | | r1615: the status queue declared itself full (free=0) while a critical completion event was pending and the old path dropped the event immediately (r1614: 'status ring full ... event dropped' during the X/GR bring-up). Critical event wake-ups now pump the guest's consumption cursor for up to 200 ms (1 ms sleeps, cursor re-read under the stat lock) before a drop is allowed; non-critical event wake-ups keep the immediate-drop policy and replies keep their 50 ms wait. The r1615c A/B shows the ring-full drops gone (only the separate 1 s event-burst cap remains, which is a rate limit, not a ring-space drop). Evidence: backups/evidence-20261002-victory/r1615/ (host dmesg window, guest poll). Unmodified-guest GL is still blocked by the nvClip modeNum bit0 (r1614); no video claim.
* vgsp-sema: ack the class-2d IMMD NOTIFY from the X DDX syncArthur Hanson Rasmusson3 days
| | | | | | | | | | | | | The X server's nvFermiSync queues the class-2d completion as IMMD_DATA methods (SET_NOTIFY_A/B + NOTIFY 0x10c WRITE_ONLY). The run-shaped watchdog form was already handled; the IMMD form fell into the default case, so the zeroed NvNotification was never authored and the server spun in WAIT (0,8,0x8000,...) with the status left IN_PROGRESS. Handle the IMMD form and treat the 0x8000 IN_PROGRESS status as armed in the keepalive scan. The mode-set then completes and the 2D sync acks (verified on the emulated vGPU: no WAIT, sema-notify2d zeroed). The A/B knob sema_2d_notify_immd=0 restores the old dropped-NOTIFY behaviour.
* vgsp: display caps window seed A/B for the guest display subsystemArthur Hanson Rasmusson3 days
|
* vgsp-rm: report GPU GART size + DMA flags in BUS_GET_INFO_V2Arthur Hanson Rasmusson3 days
|
* vgsp-gl: author the PS/TCS stage images for the emitted mask slotsArthur Hanson Rasmusson3 days
|
* vgsp-gl: raster blend/alpha/cull/point/ZCULL neutral A/B stateArthur Hanson Rasmusson3 days
|
* vgsp-gl: follow migrated screen pages in the GR copy-outArthur Hanson Rasmusson4 days
|
* vgsp-gl: GS SPH placement/maps/context A/B knobsArthur Hanson Rasmusson4 days
|
* vgsp-gl: raster-enable prelude (CT_WRITE/depth/stencil/scissor) + DS reset fixArthur Hanson Rasmusson4 days
|
* vgsp-gl: GS-mode/FASTGS variants for the synth GS SPHArthur Hanson Rasmusson4 days
|
* vgsp-gl: synthesized GS SPH image + map variants for the SPH18 gateArthur Hanson Rasmusson4 days
|
* vgsp-gl: per-stage synth SPH disable mask (r1562: DS wall reduced to SPH18)Arthur Hanson Rasmusson4 days
|
* vgsp-gl: pair-safe synth SPH binds + per-stage bind disableArthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | sema_gl_sph_bind_pair_safe (default 0) emits the synth SPH-BIND block only after closing a carried-open BEGIN/END pair, removing the r1558 EC 0x0d at 0x2018/0x1614. sema_gl_sph_stage_disable (default 0, bit j = suppress synth slot j) enables per-stage A/Bs. r1560 (mask 0x35, pair-safe on): 13 beef launches, 0 Class Error, DS 900400a0 (SPH5/7/18) - the synth-block fault is gone. r1561 (stage-disable TCS): VSB 5/7 cleared but VSA/TCS validation bits returned and GS 18 persisted; the remaining bits are stage/family state, not a universal missing bind. Changed pages max 2; frame black. Evidence and ranked next step: Handoff-vGPU-IO.md SESSION 155 cont 9.
* vgsp-gl: bounded setup-push hold for maturity debuggingArthur Hanson Rasmusson4 days
| | | | | | | | | | sema_gr_setup_hold_ms (default 0, clamp 2000 ms) holds/defer the draw window while the 60216-byte setup push pin is landing, replacing the ~50% IMMATURE-SKIP lottery. Measured: 2000 ms stalls the ring behind the unreadable 0x4021004 entry (8 launches then silence), so the default stays 0; the param is a debug gate only. r1557 with hold=0 produced 64 beef launches and the DS A/B baseline 80000000->a0040a06. Evidence: Handoff cont 8.
* vgsp-gl: engine-visible MME selector seed + RT0 third-dimension seedArthur Hanson Rasmusson4 days
| | | | | | | | | | | | | | | sema_gl_mme_selector_seed (default 0) emits engine-visible 0x2380/0x2384/ 0x2388/0x238c (fixed-CB selector base>>8, d29) before the draw window; the old state seed only wrote MME shadow scratch, so with the selector programmer elided LOAD_CONSTANT_BUFFER (0x2390 <- 0xbf800000) failed with EC 0x03. r1545: 27 beef launches, 0 errors at 0x2390. sema_gl_rt0_third_dim (default 0) writes RT0 0x818 THIRD_DIMENSION=1 so the layered-RT validation matches the driver's layer-mode ONE; r1548: the 0x17e0/EC 0xd2 illegal color-target layer-vs-third-dimension error is gone and the DS reached validation with stage5 bound (0x19a0000). Both default-off; legacy bytes unchanged. Evidence: Handoff cont 5/6.
generated by cgit v1.2.3 (git 2.39.1) at 2026-11-10 17:00:46 +0000