diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-24 01:38:07 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-24 01:38:07 -0400 |
| commit | f3225a81ca384248180d77f78c3614c73dcf289d (patch) | |
| tree | ca4735c63659bd201d8cf5a2b31858cf73bf92e7 /kernel/gsp_sema_service.c | |
| parent | a61041edf3de9c63d3ac08aed2d613df45d0219b (diff) | |
| download | open-iov-f3225a81ca384248180d77f78c3614c73dcf289d.tar.gz open-iov-f3225a81ca384248180d77f78c3614c73dcf289d.zip | |
vgsp-gr r590b: the stream-order watermark must watch every ring, not engine_type!=0
The r591 draw reproduced the r568 signature (VADD bad=32735 csum=8139264,
c = a + 0) with ceback=0: the driver submits its relocation/H2D copies on
a COMPUTE channel (h=0x5c000059 registers eng=0), so the engine_type
filter skipped exactly the backlog the guard exists for.
Consider every other channel of the device (the launching channel is
excluded: its own ring legitimately runs ahead with future entries), and
read each one's live USERD GP_PUT against this pass's consumed position.
r590's validated part is unchanged: same pass snapshot, same bounded
defer, historical forward at the absolute cap (never a refusal).
Diffstat (limited to 'kernel/gsp_sema_service.c')
| -rw-r--r-- | kernel/gsp_sema_service.c | 33 |
1 files changed, 22 insertions, 11 deletions
diff --git a/kernel/gsp_sema_service.c b/kernel/gsp_sema_service.c index a0cdb2b..0f71e8b 100644 --- a/kernel/gsp_sema_service.c +++ b/kernel/gsp_sema_service.c @@ -21114,15 +21114,25 @@ static struct svc_channel *svc_pass_local; static u32 svc_pass_local_n; /* - * r590: does any CE ring of this device still hold entries this pass's pump - * has not consumed? Reads the ring's live GP_PUT from its own USERD and - * compares it (modulo the ring size) with the snapshot's last_get. A - * mismatch means the client submitted copies/fills the pump has not decoded - * yet - exactly the stream-order backlog the r541/r568 guards cannot see. + * r590: does any ring of this device still hold entries this pass's pump has + * not consumed? Reads the ring's live GP_PUT from its own USERD and compares + * it (modulo the ring size) with the snapshot's last_get. A mismatch means + * the client submitted work the pump has not decoded yet - exactly the + * stream-order backlog the r541/r568 guards cannot see. + * + * r590b (r591 draw): the driver submits its relocation/H2D copies on a + * COMPUTE channel (h=0x5c000059 registers eng=0), not a dedicated CE + * channel, so the engine_type filter skipped the very backlog this guard + * exists for. Every other channel of the device is now considered; the + * launching channel itself is excluded because its own ring legitimately + * runs ahead (its next entries are futures, not dependencies) and holding + * on it would deadlock the launch against its own channel. + * * Channels whose USERD is unreadable are skipped (their work cannot be * ordered by this mechanism anyway). */ -static bool svc_ce_stream_backlog(struct nv_vgpu_device *vgpu) +static bool svc_ce_stream_backlog(struct nv_vgpu_device *vgpu, + const struct svc_channel *self) { u32 k; @@ -21132,8 +21142,9 @@ static bool svc_ce_stream_backlog(struct nv_vgpu_device *vgpu) const struct svc_channel *c = &svc_pass_local[k]; u32 put = 0; - if (!c->valid || (vgpu && c->vgpu != vgpu) || - !c->engine_type) + if (!c->valid || (vgpu && c->vgpu != vgpu)) + continue; + if (self && c->h_object == self->h_object) continue; if (!c->gpfifo_entries || !c->userd_pa) continue; @@ -21172,7 +21183,7 @@ static void svc_gr_dec_dump(const struct svc_channel *ch) dstpend = svc_gr_dstpend_overlap(); copypend = svc_copy_pending(); - ceback = svc_ce_stream_backlog(NULL); + ceback = svc_ce_stream_backlog(NULL, ch); pr_info("vgsp-gr: GR-DEC h=0x%x push=0x%llx n_data=%u dropped=%u partial=%d stalled=%d dstpend=%d copypend=%d ceback=%d defer_exp=%d\n", ch->h_object, svc_gr_cand.push_va, svc_fwd_req.gr_n_data, @@ -21318,7 +21329,7 @@ static bool svc_gr_request(struct nv_vgpu_device *vgpu, if (gsp_phys_gr_dec_log_max && (svc_fwd_req.gr_dropped > 0 || svc_fwd_req.gr_arg_partial || svc_gr_data_stalled || svc_gr_dstpend_overlap() || - svc_copy_pending() || svc_ce_stream_backlog(vgpu))) + svc_copy_pending() || svc_ce_stream_backlog(vgpu, ch))) svc_gr_dec_dump(ch); /* * r541: launch-ordering guard. The fill's data pages are what the @@ -21401,7 +21412,7 @@ static bool svc_gr_request(struct nv_vgpu_device *vgpu, * historical forward stands (witnessed) - the guard delays a launch, * it never refuses one, so it cannot recreate r588's mail refusal. */ - if (svc_ce_stream_backlog(vgpu)) { + if (svc_ce_stream_backlog(vgpu, ch)) { if (!svc_gr_defer_expired(svc_gr_cand.push_va)) { clear_bit_unlock(SVC_FWD_INFLIGHT, &svc_fwd_state); mutex_unlock(&svc_fwd_lock); |
