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.

1 files changed, 12 insertions, 0 deletions

diff --git a/kernel/gsp_rm_emulation.c b/kernel/gsp_rm_emulation.c
index 03f861e..d6412c3 100644
--- a/kernel/gsp_rm_emulation.c
+++ b/kernel/gsp_rm_emulation.c
@@ -4267,6 +4267,18 @@ static void gsp_rm_handle_rm_control(struct gsp_emu_context *ctx,
 					     "vgsp-rm:   promote[%u] bufferId=%u bInitialize=%u bNonmapped=%u physAttr=0x%x pa=0x%llx va=0x%llx size=0x%llx",
 					     i, bid, e[30], e[31], attr, pa,
 					     eva, esz);
+				/*
+				 * r820: register the driver's own statement
+				 * of this kernel buffer's backing (r817
+				 * Xorg GL init: the page-table walk answered
+				 * a stale zero page for the pushbuffer VA
+				 * while this entry named the real one; a
+				 * userspace pin scanner can never cover
+				 * kernel-owned buffers). See
+				 * gsp_sema_service_promote_add().
+				 */
+				gsp_sema_service_promote_add(eva, pa, esz,
+							     attr, bid);
 			}
 		}
 		out_status = 0;