| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
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.
|
