vgsp-sema: resolve the CE push buffer from the kernel chain (second-client stall)

The second CUDA client's GPFIFO entries in the CE push-buffer window
(0x120000000) had no injected pin: that window is never mapped into the
client's pagemap, so the scanner's window scan cannot see it, and its
only supplier - the one-shot uvbp kprobe event - is raced by two trace
clears (the scanner's pid-switch clear and semfix's trace-tail clear).
When the event loses the race the entry reads fall back to the ~250 ms
content rescue, which is the second-client stall and the same
resolution-miss class as the ISSUE-0001 lottery.

The guest scanner now walks channel->pool->manager->pushbuffer->rm_mem
in kernel memory with kcore and pins the push-buffer pages directly (no
trace event to lose), and the trace reader's dedup marks reset on a
client switch so a reused kptr cannot suppress the new client's #pb.

Boot evidence (r112): rescue reject ipin=0 for va_page=0x120023000,
rescue scans 175 ms - 1 s each, want incrementing to 39. Smoke test of
this fix on the stalled VM: 478 pin runs (~7955 pages) streamed within
seconds, first va=0x120000000 -> pa=0x108090000. A bounded kernel log
now prints the first CE push-buffer pins of each session.

1 files changed, 24 insertions, 1 deletions

diff --git a/kernel/gsp_sema_service.c b/kernel/gsp_sema_service.c
index 0a97cea..d68b3d3 100644
--- a/kernel/gsp_sema_service.c
+++ b/kernel/gsp_sema_service.c
@@ -928,6 +928,14 @@ static int svc_write_ap(struct nv_vgpu_device *vgpu, u64 addr, u32 aperture,
 static bool svc_gr_content_rearm;
 
 /*
+ * m149 second-client stall evidence: the CE push-buffer window pins are the
+ * translation source the second session's GPFIFO entries need; log the
+ * first few per session (reset on channel registration) so a boot shows
+ * whether they arrived.
+ */
+static u32 svc_cepin_log;
+
+/*
  * m148 (second-client wedge): re-arm the per-rank one-shot ring/push-buffer
  * latches for a (re-)registered channel. The guest driver rebuilds the GSP
  * session for every client context and RM reuses the same object handles and
@@ -970,8 +978,10 @@ void gsp_sema_service_channel_add(const struct sema_channel_desc *desc)
 	if (!desc || !desc->h_object || !desc->gpfifo_va ||
 	    desc->gpfifo_entries < 2)
 		return;
-	if (!desc->engine_type)
+	if (!desc->engine_type) {
 		WRITE_ONCE(svc_gr_content_rearm, true);
+		svc_cepin_log = 0;
+	}
 
 	/*
 	 * ISSUE-0002: a session-end flush may still be pending on svc_thread.
@@ -14995,6 +15005,19 @@ static void svc_handle_map_add(void)
 			svc_ipin_store(req.va + off, req.pa + off, ap);
 			svc_lat_store(req.va + off, req.pa + off, ap);
 		}
+		/*
+		 * m149: bounded per-session evidence that the CE push-buffer
+		 * pins arrived - the source the second session's ring entries
+		 * resolve through.
+		 */
+		if (ap == SVC_APERTURE_SYS && req.va >= 0x120000000ULL &&
+		    req.va < 0x121000000ULL && svc_cepin_log < 4) {
+			svc_cepin_log++;
+			pr_info("sema-svc: CE push-buffer pin va=0x%llx pa=0x%llx len=0x%llx (%u/4)\n",
+				(unsigned long long)req.va,
+				(unsigned long long)req.pa,
+				(unsigned long long)req.len, svc_cepin_log);
+		}
 		rewound = true;
 		if (gsp_sema_dbg)
 			pr_info_ratelimited("sema-svc: injected mapping va=0x%llx -> pa=0x%llx len=0x%llx (%s)\n",