vgsp-gr r611: the stream-order watermark considers only op-carrying channels - sibling launch rings caused mutual deferral

r607 made the CE submission watermark watch every other ring. That caught
the copy channel the r568 class needs, but it also caught sibling GR LAUNCH
channels, whose rings legitimately hold the client own future launches:
streams2s two stream channels (h=0x5c00001f/23) each saw the others
published entry as backlog, deferred for the full 15 s cap, and the r586
fail-closed then refused BOTH kernels (r610c streams2 as the first client of
a fresh boot: every launch REFUSED, STREAMS n=32768 bad=65534).

A channel that carries the client stream-ordered memory work is exactly a
channel that has decoded a transfer op; measured across r606/r609/r610c, ops
appear only on the 0x5c000059 copy family and the CE ranks, and the GR
launch channels decode none. Mark it in the op-append block (ever_ops) and
scope the watermark to those channels: the r606 red-draw copy channel stays
in scope, the sibling launch rings no longer defer.

1 files changed, 32 insertions, 0 deletions

diff --git a/kernel/gsp_sema_service.c b/kernel/gsp_sema_service.c
index fa11f68..00d9b56 100644
--- a/kernel/gsp_sema_service.c
+++ b/kernel/gsp_sema_service.c
@@ -318,6 +318,21 @@ struct svc_channel {
 				 * the end with no operand left pending, so a
 				 * replay suppresses every op. When clear, the
 				 * done bitmap decides per op (retry path). */
+	bool	ever_ops;	/* r611: this channel has decoded at least one
+				 * transfer op (copy/fill), i.e. it carries the
+				 * client's stream-ordered memory work. The r607
+				 * stream-order watermark considers only such
+				 * channels: a sibling GR LAUNCH channel's ring
+				 * legitimately holds future launches, and
+				 * deferring on those creates mutual deferral
+				 * between the client's own launch channels
+				 * (streams2: launches on h=0x5c00001f/23 each
+				 * saw the other's unconsumed entry, burned the
+				 * 15 s cap and were refused fail-closed - the
+				 * r610c stream class red). Measured r606/r609/
+				 * r610c: op-decoding channels are exactly the
+				 * copy ranks (0x5c000059 family) and the CE
+				 * ranks; launch channels decode no ops. */
 	u64	slot_ops_hash[SVC_GPFIFO_MAX_BITS];
 				/* Content witness for slot_ops_ident: the
 				 * FNV-1a hash of the push bytes the identity
@@ -11560,6 +11575,11 @@ static void svc_decode_stream(struct nv_vgpu_device *vgpu, const u8 *buf,
 			if (n_ops != n_ops_before) {
 				struct svc_memset_op *lm = &ops[n_ops - 1];
 
+				/* r611: this channel carries transfer work
+				 * (see ever_ops) - the stream-order
+				 * watermark's scope. */
+				ch->ever_ops = true;
+
 				/*
 				 * fail4 CONT.53: H2D-shaped copies (virtual
 				 * device destination, virtual host source)
@@ -21316,6 +21336,16 @@ static u32 svc_pass_local_n;
  *
  * Channels whose USERD is unreadable are skipped (their work cannot be
  * ordered by this mechanism anyway).
+ *
+ * r611: only channels that carry transfer ops are considered (ever_ops).
+ * The r607 blanket "every other ring" caught sibling GR LAUNCH channels
+ * whose rings hold the client's own future launches: streams2's two stream
+ * channels (h=0x5c00001f/23) each deferred on the other's published entry
+ * for the full 15 s cap, then the r586 fail-closed refused both kernels
+ * (measured r610c: every streams2 launch REFUSED, bad=65534). A launch
+ * channel decodes no ops (measured r606/r609/r610c: ops appear only on the
+ * 0x5c000059 copy family and the CE ranks), so the flag separates them
+ * cleanly while keeping the r606 red-draw copy channel in scope.
  */
 static bool svc_ce_stream_backlog(struct nv_vgpu_device *vgpu,
 				  const struct svc_channel *self)
@@ -21332,6 +21362,8 @@ static bool svc_ce_stream_backlog(struct nv_vgpu_device *vgpu,
 			continue;
 		if (self && c->h_object == self->h_object)
 			continue;
+		if (!c->ever_ops)
+			continue;
 		if (!c->gpfifo_entries || !c->userd_pa)
 			continue;
 		if (svc_read_ap(vgpu ? vgpu : c->vgpu,