| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- gsp_sema_service: never fabricate scrub completions. The guest
decrements its scrub-list size by the reported finish delta without
a guard, so a fabricated delta larger than the pending list
underflows it and the guest spins (~2^64) under the scrubber mutex
(r1766-r1768 X soft-locks and guest panics; root-caused by static
analysis + gdbstub decode of lastSeen/lastSubmitted/scrubListSize).
The release now mirrors the registered channel's own ring: count new
valid pushes (wrap-safe snapshot delta) and set the finish word
forward-only to the cumulative count - exactly the work the guest
submitted, never more. False ring-page registrations are detected
and skipped (a mis-registered ring page had its first GPFIFO entry
clobbered by an all-ones write). sema_scrub_ramp=0 keeps the legacy
all-ones release for A/B; the finish word is never all-ones with the
ledger enabled.
- gsp_rm_emulation/gsp_display_engine: gate the hSrcResource==0 -> alloc
parent event association behind ev_assoc (default 0) and keep strict
display-event posting behind disp_events_strict (default 0) - both
remain A/B knobs for the flip-event delivery fix.
- Live validation (r1769): 4/4 green boots, 0 panics, 0 wedges;
glprobe pixel=ff0000ff; gl_frames 500/500 non-black frames captured
to a 45 s 640x480 mp4 via pbuffer -> sysmem -> ivshmem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
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.
|
