r496b the X/GL channel bring-up: sysmem ring discovery by content + VRAM USERD shape scanHEADmaster

With the GR classification fixed the pump reaches the X driver's 3D channel
for the first time, but both of its structures are outside every existing
translation source: the CPU RM maps the pushbuffer's NV01_MEMORY_SYSTEM
surface locally (no SET_PAGE_DIRECTORY, no rm_mem record carrying the ring
VA - the targeted resolve scans all of guest RAM and finds nothing), and the
driver's USERD GP_PUT write lands in the emulated VRAM at a BAR1-window
offset (observed: fb 0x80000) that is neither the registered memdesc base
(0x10000, pool-relative) nor ring-derived.

Two content scans close the gap, both validated so a wrong hit costs a
failed probe, not a bad pin:
- svc_gr_ram_ring_scan: the driver's kickoff writes GPFIFO entries whose
  pushbuffer VAs sit just BELOW the ring VA in the same allocation (main
  pushbuffer first, GPFIFO after - nvidia-push-priv.h). A page whose first
  two 8-byte entries both name such VAs with sane lengths is the ring; the
  ring page is pinned validated and the 2 MB allocation window as guesses
  (the ring entry and pushbuffer reads resolve through it). Sliced 512 MB
  per pass, cursor-resumed, 16 slices max.
- svc_userd_fb_scan (svc_chan_userd GR fallback): scan the VRAM for the
  USERD shape (GP_PUT at +0x8c in [1..entries], GP_GET at +0x88 <= put) and
  validate each hit against the ring: every entry the put claims must
  decode to a pushbuffer VA in the ring's allocation window. A foreign
  channel's USERD cannot pass that test. 8 bounded retries (the kickoff
  lands a few passes after registration).

0 files changed, 0 insertions, 0 deletions