vgsp: X/GL wall broken - PROMOTE_CTX registry, small trusted-NOP acceptance, push-scoped release deferral

The X server now starts on the emulated vGPU and GLX runs on the real
NVIDIA driver: Xorg :0 passes its DMA sanity push and ScreenInit, and
DISPLAY=:0 glxinfo reports 'OpenGL 4.6.0 NVIDIA 570.144' with direct
rendering; GZDOOM 4.14.2 launches and renders.  Before this, every X
start died at 'NVIDIA(GPU-0): Failed to initialize DMA' (the
__nvPushTestPushBuffer 10 s GP_GET wait) and no nvidia-push kernel
buffer could be resolved.

What each piece fixes (all observed live on the r817->r827 cycles):

- sema: register the driver's PROMOTE_CTX context-buffer statements as
  a VA->PA registry, consulted as the LAST resort after every walk.
  A promoted (va, pa) pair is a VA-space booking, not a mapping: its
  span can swallow other buffers' VAs (the ctx MAIN booking covered the
  channel GPFIFO VA and range arithmetic answered the entry validation
  with MAIN.pa+offset, a zero page - the latch never fired, r823), and
  even its base page can host a separately mapped buffer (the PATCH
  booking's base VA hosts nvidia-push's 4 KB progress semaphore; the
  release landed in the booking's page while the driver's own polled
  page stayed zero, r826).  The walks describe the real mappings and
  must answer first.

- sema: an all-zero GR push of <= 16 bytes resolved by the trusted
  chain (src=4) is accepted as the driver's NOP sanity push
  (NVA16F_DMA_NOP is a single zero dword; real launches are hundreds of
  bytes).  The r496e acceptance required a content-scanned ring, which
  the X/GL channel is not.

- sema: the wave-1.5 release deferral is push-scoped.  A release whose
  push owns no captured forward candidate has nothing to wait for; it
  applies inline (the progress-tracker semaphore release used to be
  recorded and dropped at every pass reset while an unrelated lingering
  candidate armed the global defer).

- sema: the m164 no-capture hold no longer arms for the accepted zero
  NOP - it held the NOP entry for its 6 s window 'forcing capture' of a
  launch that cannot exist.

- sema: once the ring resolves, the USERD latch scan may retry past its
  8-scan cap (the client's VAS directory registration lost the race
  against the 10 s DMA window when a rebuild stretched the pass cadence,
  r820).

- sema: dbg-gated USERD-scan decision witnesses (rejection reason, sweep
  summary, per-call state), GR-only and budgeted.

Known next issue (not this change): sustained X/GL rendering traffic
wedges the guest RC watchdog ('NVRM: krcWatchdog_IMPL: GPU is probably
locked') after minutes of GZDOOM/GLX activity; the FIFO service itself
keeps consuming.

0 files changed, 0 insertions, 0 deletions