summaryrefslogtreecommitdiffstats
path: root/kernel/gsp_display_engine.c
Commit message (Collapse)AuthorAge
* vgsp-disp: never publish GET past PUT; bounded no-parse push dumpArthur Hanson Rasmusson12 hours
| | | | | | | | | | | | | | | 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 Rasmusson13 hours
| | | | | | | | 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 Rasmusson13 hours
| | | | | | | | | | | | 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-disp: byte method addresses in the push parser (x4)Arthur Hanson Rasmusson14 hours
| | | | | | | | | 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 Rasmusson14 hours
| | | | | | | | | | 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 Rasmusson20 hours
| | | | | | | | | | | | | 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 Rasmusson20 hours
| | | | | | | | | | | | | 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 Rasmusson24 hours
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.