vgsp-gr r564: refuse a degenerate launch data set before the engine sees it

r565 evidence: the fill dropped 4 argument bases (GRFILL-DROP), RDW showed
nrecs=2 where healthy launches run 968-969, the launch was still submitted
and the backend timed out after ~19 s (GR forward failed rc=-110); the
tail then authored the software release and the client kept spinning on a
completion for a kernel that never ran - 20 s of backend occupancy plus a
false completion, and a plausible wedge source for the following clients.

gsp_phys_gr_submit now refuses n_data < GSP_PHYS_GR_MIN_DATA_RECS (16)
with a loud line, failing fast into the same software-completion fallback
without touching the engine.

1 files changed, 26 insertions, 0 deletions

diff --git a/kernel/gsp_phys_booter.c b/kernel/gsp_phys_booter.c
index 82c88dc..7ba74ce 100644
--- a/kernel/gsp_phys_booter.c
+++ b/kernel/gsp_phys_booter.c
@@ -17599,6 +17599,13 @@ static u32 gsp_phys_gr_data_bi(u64 reloc_va)
  * gsp-phys-work item is the only caller, reset per submission exactly like
  * bounce_csum_in.
  */
+/*
+ * r564: minimum data records for a forwardable launch. Healthy vadd-class
+ * 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).
+ */
+#define GSP_PHYS_GR_MIN_DATA_RECS 16u
 #define GSP_PHYS_GR_GAP_MAX	4096u	/* total late pages per launch */
 /*
  * relfix PART 3 (r217 span containment): the late path authors ONLY the
@@ -19196,6 +19203,25 @@ int gsp_phys_backend_guest_gr_submit(const struct gsp_phys_gr_submit *req,
 		gsp_phys_gr_refused++;
 		return -EINVAL;
 	}
+	/*
+	 * r564: refuse a degenerate data set BEFORE the engine ever sees it.
+	 * r565 evidence: the fill dropped 4 argument bases (GRFILL-DROP),
+	 * RDW showed nrecs=2 where healthy launches run 968-969, the launch
+	 * was still submitted and the backend timed out after ~19 s
+	 * ("GR forward failed rc=-110"), after which the tail authored the
+	 * software release and the client kept spinning on a completion for a
+	 * kernel that never ran - the worst of both (20 s of backend
+	 * occupancy plus a false completion). Refusing up front fails fast
+	 * 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) {
+		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->push_va);
+		return -ENODATA;
+	}
 	if (!gsp_phys_backend_gr_ready() || !gsp_phys_guest_mem_enabled() ||
 	    gsp_phys_dma_domain_identity() != 1 || !gsp_phys_guest_ram_active()) {
 		gsp_phys_gr_refused++;