summaryrefslogtreecommitdiffstats
path: root/kernel
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-23 09:30:03 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-23 09:30:03 -0400
commitfd88404e313927a88c9d538106adc1b9894b692e (patch)
tree82c0f81873d379e31756ba541decbd10ceb70d69 /kernel
parent51e50d937800db01bd95010ad54ef2c4ea140b75 (diff)
downloadopen-iov-fd88404e313927a88c9d538106adc1b9894b692e.tar.gz
open-iov-fd88404e313927a88c9d538106adc1b9894b692e.zip
vgsp-sema: bounded fallback registration for a parked VAS candidate (15 s)
The VAS candidate verification needs the client's ring to be found by the RAM content scan; on a boot where that never anchors the ring the candidate stays parked forever and every launch operand walk fails rc=-2 (observed: pd_found=0, vas[0] holding an internal pdb, walks stuck at 9555 successes with 114 K attempts while the client spun for minutes). After 15 s parked, register the candidate unverified with a loud log: it came from the client's own RM publish and the newest-first walk order keeps an older stale directory from winning, so the bounded wait's registration is the lesser evil.
Diffstat (limited to 'kernel')
-rw-r--r--kernel/gsp_sema_service.c49
1 files changed, 49 insertions, 0 deletions
diff --git a/kernel/gsp_sema_service.c b/kernel/gsp_sema_service.c
index dcce4b5..cd7ff73 100644
--- a/kernel/gsp_sema_service.c
+++ b/kernel/gsp_sema_service.c
@@ -1674,6 +1674,7 @@ static struct {
u64 pdb;
u32 entries;
bool vidmem;
+ unsigned long stamp; /* r537: park time for the bounded fallback */
} svc_vas_cand[SVC_VAS_CAND_MAX];
static int svc_gmmu_walk(struct nv_vgpu_device *vgpu, u64 pdb, u32 entries,
@@ -1697,12 +1698,53 @@ void gsp_sema_service_vaspace_candidate_add(u32 h_vaspace, u64 pdb,
svc_vas_cand[i].pdb = pdb;
svc_vas_cand[i].entries = entries;
svc_vas_cand[i].vidmem = vidmem;
+ svc_vas_cand[i].stamp = jiffies;
return;
}
}
}
/*
+ * r537 bounded fallback: register a parked candidate that has waited for
+ * its content-verified ring walk longer than SVC_VAS_CAND_AGE_MS. The
+ * verification (svc_vas_candidates_verify) needs the client's ring to be
+ * found by the RAM content scan; on a boot where that scan never anchors
+ * the ring (observed: pd_found=0 and every launch operand walk rc=-2 for
+ * minutes, the client spinning with its data VAs unresolvable) the
+ * candidate stays parked forever and the client can never proceed. The
+ * candidate itself came from the client's own RM publish (its VAS
+ * handle), and the r459 newest-first walk order keeps an older stale
+ * directory from winning, so after the bounded wait the registration is
+ * the lesser evil; it is logged loudly for the record.
+ */
+#define SVC_VAS_CAND_AGE_MS 15000u
+
+static void svc_vas_candidates_age_out(struct nv_vgpu_device *vgpu)
+{
+ int i;
+
+ for (i = 0; i < SVC_VAS_CAND_MAX; i++) {
+ struct sema_vaspace_desc d;
+
+ if (!svc_vas_cand[i].valid)
+ continue;
+ if (time_before(jiffies, svc_vas_cand[i].stamp +
+ msecs_to_jiffies(SVC_VAS_CAND_AGE_MS)))
+ continue;
+ memset(&d, 0, sizeof(d));
+ d.h_vaspace = svc_vas_cand[i].h_vaspace;
+ d.pdb = svc_vas_cand[i].pdb;
+ d.num_entries = svc_vas_cand[i].entries;
+ d.b_vidmem = svc_vas_cand[i].vidmem;
+ pr_warn("sema-svc: VAS 0x%x page directory registered UNVERIFIED after %u ms parked (pdb=0x%llx entries=%u; the content-verified ring walk never anchored this boot)\n",
+ d.h_vaspace, SVC_VAS_CAND_AGE_MS, d.pdb,
+ d.num_entries);
+ gsp_sema_service_vaspace_add(&d);
+ svc_vas_cand[i].valid = false;
+ }
+}
+
+/*
* Verify each parked candidate against one content-validated translation
* (the ring VA -> PA the RAM scan just proved): walk the ring page through
* the candidate and register only the directory that reproduces it. Runs on
@@ -24296,6 +24338,13 @@ static int svc_thread(void *arg)
}
/*
+ * r537: bounded fallback for a parked VAS candidate
+ * whose content-verified ring walk never anchored
+ * (see svc_vas_candidates_age_out).
+ */
+ svc_vas_candidates_age_out(vgpu);
+
+ /*
* Channel-driven execution: notice submissions as they
* are made and run the pushed work immediately, so the
* guest's UVM progress waits complete in milliseconds