diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-27 10:26:38 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-27 10:26:38 -0400 |
| commit | bd1f27476fc11dc0bc45eb1aa666e352f34a0168 (patch) | |
| tree | c6542466394f637a077d8e89f4d5f12b3cc5825f /wiki/open-iov.org/index.php?title=GPU_Support&action=history.html | |
| parent | cb1653d62f521943497e5705803f461ab7041dda (diff) | |
| download | open-iov-bd1f27476fc11dc0bc45eb1aa666e352f34a0168.tar.gz open-iov-bd1f27476fc11dc0bc45eb1aa666e352f34a0168.zip | |
vgsp: client-session boundary fixes - WD ring scan gate + forced session flush
Two changes from the r839/r840 multi-client forensics (session 147):
1. The guest-RAM content scan for a GR ring must not run for the kernel
RC-watchdog channel (h=0x31415900). Its ring is a plain kernel allocation
always resolvable through the driver-published VAS walk; on r840 the walk
lost a registration race, the scan latched a foreign garbage page, and
the bad latch poisoned the driver's DMA test ('Failed to initialize DMA',
Xorg died). Gated, the walk retries per pass; r841 Xorg#1 passes DMA
(DMAFAIL=0) where r840 failed.
2. sema_force_flush module parameter + gsp_sema_service_sess_flush_force():
execute the ISSUE-0002 client-session flush even with live channels. The
channel-close trigger never fires on real boots (driver-global channels
stay valid), so later client sessions inherited stale discovery state.
Verified on r841: flush executes mid-boot, Xorg survives it and
re-registers its channels.
Remaining wall (addendum 9): GR client channels' pushbuffer reads return
all-zero through the trusted translation (va=0x4000000-class, src=4), so
first entries never complete and GL clients never render.
Diffstat (limited to 'wiki/open-iov.org/index.php?title=GPU_Support&action=history.html')
0 files changed, 0 insertions, 0 deletions
