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, 17 insertions, 0 deletions

diff --git a/kernel/gsp_sema_service.h b/kernel/gsp_sema_service.h
index 8d63a72..94faf82 100644
--- a/kernel/gsp_sema_service.h
+++ b/kernel/gsp_sema_service.h
@@ -89,6 +89,23 @@ struct sema_vaspace_desc {
 
 void gsp_sema_service_vaspace_add(const struct sema_vaspace_desc *desc);
 void gsp_sema_service_vaspace_del(u32 h_vaspace);
+
+/*
+ * r820: a driver-declared kernel-buffer translation from an
+ * NV2080_CTRL_CMD_GPU_PROMOTE_CTX entry (gpuVirtAddr/gpuPhysAddr/size/
+ * physAttr of one context buffer). These buffers - the nvidia-push
+ * pushbuffer, the progress-tracker segment, the FECS/patch/access-map
+ * blocks - are kernel-owned, so the userspace pin scanner cannot cover
+ * them and the page-table walk can answer with a stale/wrong page
+ * (r817 Xorg GL init: the walk resolved the 64 KB pushbuffer VA to a
+ * zero page while the promote entry named the real one). The sema
+ * service consults these records before the learned cache and the walks
+ * in svc_lookup_trusted; newest statement per VA wins. VA-only bookings
+ * (zero pa/size) and bNonmapped entries (va=0) are ignored. Records are
+ * session state, cleared by svc_session_flush.
+ */
+void gsp_sema_service_promote_add(u64 va, u64 pa, u64 size, u32 phys_attr,
+				  u32 buffer_id);
 /*
  * r496j: park a page-directory candidate (from COPY_SERVER_PDES) until a
  * content-validated walk proves it belongs to a live client; only then is