vgsp: channel-scoped VA resolution via the channel's own VAS (r835)

Every RM client maps different objects at the same numeric VAs (all
clients' windows sit at 0x1200xxxxx), so the global VA-keyed pin/lat/map
layers conflate them across clients. Live walk_probe evidence (r834):
the X server's ring VA 0x120090000 resolved through the GL client's page
tables (vas h=0xcaf00005 -> a zero page) while the X client's own VAS
(vas h=0x10005) holds the real page (pa=0x1294fa000). That conflation is
what wedged the X server's readback wait and starved the RC watchdog's
ring (its pushes decoded as empty).

* Parse NV_CHANNEL_ALLOC_PARAMS.hVASpace (@28; layout confirmed by the
  struct's own known offsets) at channel registration and carry it on
  svc_channel.
* svc_chanvas_lookup: resolve a VA through the serviced channel's own
  VAS page tables first (svc_cur_vas, refreshed per channel turn and in
  the decode path). The hook sits at the head of svc_lookup_trusted, so
  ring, push, release and notifier resolution all inherit it; a failed
  walk falls through to the old chain unchanged.

Live r835: X's XShmGetImage readback, previously never completing,
returned after its long wait and a frame reached the kvmfr BAR (first
frame content still black and readback latency still ~87 s; the
guest-side fbcopy_pub framebuffer reader tool is added for the
direct-VRAM capture path, find/pub/test modes).

0 files changed, 0 insertions, 0 deletions