vgsp: client-session boundary fixes - WD ring scan gate + forced session flush

Two changes from the r839/r840 multi-client forensics (session 147):

1. The guest-RAM content scan for a GR ring must not run for the kernel
   RC-watchdog channel (h=0x31415900). Its ring is a plain kernel allocation
   always resolvable through the driver-published VAS walk; on r840 the walk
   lost a registration race, the scan latched a foreign garbage page, and
   the bad latch poisoned the driver's DMA test ('Failed to initialize DMA',
   Xorg died). Gated, the walk retries per pass; r841 Xorg#1 passes DMA
   (DMAFAIL=0) where r840 failed.

2. sema_force_flush module parameter + gsp_sema_service_sess_flush_force():
   execute the ISSUE-0002 client-session flush even with live channels. The
   channel-close trigger never fires on real boots (driver-global channels
   stay valid), so later client sessions inherited stale discovery state.
   Verified on r841: flush executes mid-boot, Xorg survives it and
   re-registers its channels.

Remaining wall (addendum 9): GR client channels' pushbuffer reads return
all-zero through the trusted translation (va=0x4000000-class, src=4), so
first entries never complete and GL clients never render.

1 files changed, 6 insertions, 0 deletions

diff --git a/kernel/gsp_sema_service.h b/kernel/gsp_sema_service.h
index 63c7f82..2184826 100644
--- a/kernel/gsp_sema_service.h
+++ b/kernel/gsp_sema_service.h
@@ -120,6 +120,12 @@ void gsp_sema_service_vaspace_candidate_add(u32 h_vaspace, u64 pdb,
  * session flushes keep that state - see svc_session_flush. */
 void gsp_sema_service_guest_reset(void);
 
+/*
+ * ISSUE-0002 aid: force a client-session flush that executes even while
+ * channels are live (see addendum 8 and the sema_force_flush parameter).
+ */
+void gsp_sema_service_sess_flush_force(void);
+
 int  gsp_sema_service_start(void);
 void gsp_sema_service_stop(void);
 int  gsp_sema_service_probe(u64 gpu_va, u32 count);