vgsp-sema: SESSION 127 C5C0 TRANSLATOR v1 - the Vulkan compute launch captured, filled and forwarded (and its copy-out executed) through the CUDA QMD machinery

The Vulkan client's compute dispatch is an inline-QMD launch that lives in
the PRE-BUILT ring continuation beyond GP_PUT (the earlier analysis only
inspected the put-bounded pushes' idx7/idx12 and concluded 'no inline QMD'):
beec0100 idx23 carries SET_INLINE_QMD_ADDRESS_B (0x31c = 0x4b85f, the upper
half absent) plus the 64-word LOAD_INLINE_QMD_DATA (0x320) run - grid 40x30,
prog=0xdfd8feb900 (the SASS page), param=0x4b86000, release0=0x4b85e08/1 -
and idx24 carries the TURING_DMA_COPY_A (0xC5B5, subch 4) image->buffer
copy-out (src=0xdfd8d60000 dst=0x050b0000, 640x480 RGBA rows) plus the
SEND_PCAS schedule (0x2b4 = qmd>>8, 0x2bc = SCHEDULE).

Pieces landed (all service-thread, all bounded/logged):

- svc_gr_ahead_push (the sema_gr_ahead sweep parser) is now a strict
  tail-aware translated decode of one continuation entry: it accepts a
  method stream whose final inline run is completed from the NEXT ring entry
  (the driver splits big LOAD_INLINE_DATA payloads into a dedicated data
  slot entry: beef0100 idx00->idx01 256 B, idx08->idx09 12288 B), feeds the
  C5C0 inline-QMD window to svc_qmd_accum (capture via the standard CUDA QMD
  candidate), materializes GRCE/KEPLER_INLINE_TO_MEMORY_B LOAD_INLINE_DATA
  writes into the VA shadow exactly like the main decode (once-only keyed;
  recorded in the dst ring for the fill's inline-served pages), parses the
  C5B5 copy operands (0x400/0x404/0x408/0x40c/0x410/0x414/0x418/0x41c,
  0x300 LAUNCH_DMA, 0x700/0x708 remap) into a pending copy list, and queues
  the release groups minus a release a live launch candidate owns (that word
  belongs to the completion edge, so the client's fence can never clear on a
  pre-render image).
- The parser reads the run data words correctly (w3 fix; the GRCE 0x18c
  operand was being read from the next run's header word, which sent the
  1568 B parameter-bank write to a bogus destination).
- svc_qmd_accum: accept the ADDRESS_B-only inline-QMD form (implicit zero
  upper half) so qmd_dev_va is real for the Vulkan launch.
- svc_gr_page_note + svc_gr_req_fill: resolve a client-VAS page through the
  registered-VAS walk when the trusted sources do not carry it (the Vulkan
  QMD's program/parameter/descriptor pages are client-managed vidmem; the
  fill refused the whole launch with -ENOENT before this).
- The QMD capture's inline recs are filtered to the pages the captured QMD
  names (a stale session-wide rec destination made the fill refuse with
  ENOENT va=0x80412000 qmd_word=NONE).
- Pending GRCE copy-out list executed on the launch completion edge
  (svc_fwd_hold_gr_release and svc_fwd_outcome_check) before the guest
  release is authored, with a bounded no-forward fallback at the sweep; the
  copy itself runs through the standard svc_copy executor (observed:
  'copy done h=0xbeec0100 dst=0x50b0000 bytes=0x12c000 rows=480 rc=0').
- The pump offers a sweep-captured launch every pass (svc_gr_request) - the
  continuation launch's only dispatch path - and retires pending copies when
  no forward is owed.
- gsp_phys_gr_min_data (module param, default 16): the degenerate-data-set
  refusal threshold is now tunable; the Vulkan dispatch's operand set is a
  handful of records, not the CUDA-era 968.
- Bounded witnesses for the request paths (first-N/periodic: no-candidate,
  backend-not-ready, hold-busy, inflight-busy, fill-ENOENT) and the capture
  tail dump is now sema_dbg-gated with a 4/boot budget (it flooded dmesg).

Live status (r726, cycles r719..r726): the client runs green through the
fence (VKFRAME seq/DONE/IDLE, 3 PPMs) with no in-flight client assist; the
sweep captures the launch ('launch captured ... qmd=0x4b85f00
prog=0xdfd8feb900 param=0x4b86000'); the fill resolves the QMD pages
(page-note src=walk) and now passes its ENOENT gate; the copy-out executes
for every frame. The physical launch itself is still refused: the fill
yields n_data=0 because the launch's operand CONTENT (the SASS at
prog=0xdfd8feb900, the descriptor data) is delivered by the driver through
the MME / inline-to-memory engine upload stream (beec0100 idx7/idx12,
beef0100 idx08), which the emulation does not execute - the pages the QMD
names stay zero in the emulated vidmem. That engine-side upload path is the
next work item; sessions r719..r726, evidence in the handoff.

No host reboots; 0 oopses; the fetch of the CUDA battery on a fresh boot
follows separately.

1 files changed, 24 insertions, 2 deletions

diff --git a/kernel/gsp_phys_booter.c b/kernel/gsp_phys_booter.c
index 6fae2f2..65fa429 100644
--- a/kernel/gsp_phys_booter.c
+++ b/kernel/gsp_phys_booter.c
@@ -17678,8 +17678,29 @@ static u32 gsp_phys_gr_data_bi(u64 reloc_va)
  * launches resolve 968-969 records (the client's whole arena); a launch
  * with only a handful after the fill's drops has an unresolved argument
  * set and must not be handed to the engine (see the submit guard).
+ *
+ * SESSION 127: the Vulkan inline-QMD launch (the C5C0 translator) is a
+ * compute dispatch whose operand set is one descriptor page and one
+ * parameter bank - a handful of records is healthy for it. Tunable module
+ * parameter (default 16 preserves the CUDA-era threshold); the translator
+ * cycles pass gsp_phys_gr_min_data=2.
  */
 #define GSP_PHYS_GR_MIN_DATA_RECS 16u
+static unsigned int gsp_phys_gr_min_data_param = GSP_PHYS_GR_MIN_DATA_RECS;
+module_param_named(gsp_phys_gr_min_data, gsp_phys_gr_min_data_param, uint, 0644);
+MODULE_PARM_DESC(gsp_phys_gr_min_data,
+	"GR submit minimum data records (degenerate-set refusal threshold, clamped 1..4096; default 16)");
+
+static unsigned int gsp_phys_gr_min_data_value(void)
+{
+	unsigned int v = READ_ONCE(gsp_phys_gr_min_data_param);
+
+	if (!v)
+		v = 1;
+	if (v > 4096)
+		v = 4096;
+	return v;
+}
 #define GSP_PHYS_GR_GAP_MAX	4096u	/* total late pages per launch */
 /*
  * relfix PART 3 (r217 span containment): the late path authors ONLY the
@@ -19289,10 +19310,11 @@ int gsp_phys_backend_guest_gr_submit(const struct gsp_phys_gr_submit *req,
 	 * into the same software-completion fallback without touching the
 	 * engine, and cannot wedge it for the next client.
 	 */
-	if (req->n_data < GSP_PHYS_GR_MIN_DATA_RECS) {
+	if (req->n_data < gsp_phys_gr_min_data_value()) {
 		gsp_phys_gr_refused++;
 		pr_err_ratelimited("vgsp-gr: GR submit refused: degenerate data set n_data=%u (min %u) launch_va=0x%llx\n",
-				   req->n_data, GSP_PHYS_GR_MIN_DATA_RECS,
+				   req->n_data,
+				   gsp_phys_gr_min_data_value(),
 				   req->push_va);
 		return -ENODATA;
 	}