open-iov.git/kernel/gsp_sema_service.c, branch master

vgsp-sema: a stale-dropped pool read must not consume the residue rule (second-client fix)

2026-10-12T05:46:11+00:00

r99/r100: the fresh session's reused pool page reads the previous session's residue (cur=2) before the first genuine release (pay=1) is translated; the translated read set ch->pool_rel_seen, so every later residue release (payload <= cur) was silently dropped by the final else and the client spun at DEVICE forever. A read that applied or deferred nothing now leaves the flag clear so the r63/r64 residue re-seed still fires for the first genuine release of the session.

vgsp-sema: discover GR data candidates from the fresh inline param block (second-client fix)

2026-10-12T05:46:11+00:00

Second-client launches scanned a stale/reused guest param page that still held the FIRST client's device VAs: zero new candidates resolved, nothing was relocated, and the engine executed with unrelocated guest pointers (r97 evidence: client#1 '15 candidate ptrs, 100 pages resolved' and win0 param 160=110400; client#2 '12 candidates, 1 page' with 160=75552ec00000 unrelocated). The driver-authored inline param block is captured from the pushbuffer at request time, so scanning it makes pointer discovery independent of guest-page reuse timing. Adds svc_gr_scan_cand()/ svc_gr_scan_inline() and the DIAG win0/guest-param proof line. Client #1 stays green (4 cycles); the remaining second-client stall is the pool semaphore residue (see next commit).

vgsp: GR data path - pre-publish bounce fill, engine-change proof, ipin-first data resolution

2026-10-12T02:17:15+00:00

Two fixes and one diagnostic for the all-zero-results class (r89: smiley's 4 vadd launches reported GUEST GR LAUNCH OK yet every output word read 0): - gsp_phys_booter: copy the guest data pages into the bounce window BEFORE gsp_phys_rmcall_publish_locked() rings the doorbell. The fill used to run after the kick; the engine front end starts within ~7 ms, so the kernel could read the window before it was filled. - gsp_phys_booter: per-page checksums at copy-in, compared at copy-out; the copy-out log now reports 'N changed by engine'. An all-unchanged window after a reported completion is the front-end-ran/grid-never- dispatched signature (completion semaphores are front-end authored). The first 3 data (va,hpa,reloc) triples are logged per launch. - gsp_sema_service: svc_gr_data_fill resolves data pages through svc_ipin_lookup() first (guest-truth pins), falling back to svc_resolve_va, mirroring the pool resolver order; a wrong page here silently runs the kernel on zeros. First 16 resolved (va,pa,ap) triples are logged for post-mortem comparison against the guest's own mapping.

Revert "vgsp-sema: scope channel deletion to the owning RM client (ISSUE-0002)"

2026-10-11T21:50:53+00:00

This reverts commit 5fa773c2cd4e166d2c31a40aff9fb63e7534fec3.

Revert "vgsp-sema: scope CE/GR rank assignment to the owning client (ISSUE-0002)"

2026-10-11T21:50:52+00:00

This reverts commit 35ca086b20f04f6be5bd935fd53d08e43f67e869.

Revert "vgsp-sema: session boundary is a client change, not the last channel closing (ISSUE-0002)"

2026-10-11T21:50:52+00:00

This reverts commit 12732c5894c893344422da4fd8d075c4c43c8e8a.

Revert "vgsp-sema: keep the scrubber channel inert; publish its finish payload from GP_PUT (ISSUE-0002)"

2026-10-11T21:50:52+00:00

This reverts commit 2d0a65b8f10f8bfac935d880dd9704e7b14f5b29.

vgsp-sema: keep the scrubber channel inert; publish its finish payload from GP_PUT (ISSUE-0002)

2026-10-11T21:35:54+00:00

The CeUtils scrubber channel (entries=4096, GPU-global) stays registered across client sessions now that deletion is client-scoped, but its channel buffer memory is reused by later clients' push buffers: entry-pumping its stale ring invented work and perturbed the session (r79/r80: the first client wedged on an rwsem). The pump now skips channels with the scrubber layout (entries >= 4096) and instead publishes the word the pma scrub actually waits on - the channel buffer finish payload at gpfifo_va + 8*entries + 4 (live-verified: 0x120064000 + 0x8000 + 4 = 0x12006c004, the address from the hung client's register dump) - forward-only from the channel's own GP_PUT (one payload per submitted push, the same counter the guest's ceutilsUpdateProgress polls). Skipping the scrub's actual memset work is acceptable for the emulated vidmem: the guest's scrub clears pages of its own shadow, and the emulation's job here is the completion contract. Revisit if per-tenant vidmem scrubbing is required.

vgsp-sema: session boundary is a client change, not the last channel closing (ISSUE-0002)

2026-10-11T21:23:45+00:00

r79 regression from keeping the CeUtils scrubber channel registered (client-scoped deletion): the session flush trigger required EVERY channel to close, and the scrubber never closes, so the per-session discovery reset never ran and the next client inherited the previous session's map/pins (the r9 class; the first client of r79 wedged the guest on an rwsem with no output). The session is now keyed by owning client: channel_add records svc_sess_client and requests the flush when a channel of a DIFFERENT client registers while the previous session is live (then waits for it, exactly like a pending flush); channel_del's flush trigger counts only channels of the current session client, so persistent kernel/GPU-global channels (the scrubber) no longer keep a dead session open.

vgsp-sema: scope CE/GR rank assignment to the owning client (ISSUE-0002)

2026-10-11T20:53:37+00:00

r78 validation of the client-scoped deletion: the boot session's CeUtils scrubber channel (client != the UVM client, entries=4096) stayed registered as intended, but it consumed CE rank 0 and every UVM channel's rank shifted by one. Ring autopin and push-buffer pairing derive the ring and pool-semaphore offsets from the rank (0x121010000 + 0x30000*rank, 0x121000000 + 4*rank), so the first client's pairing went to the wrong offsets and the guest wedged on an rwsem (sysrq: rwsem_spin_on_owner). Rank is now counted only among live channels of the same owning client; the UVM client's channels keep ranks 0..5 and the kernel/GPU-global scrubber gets its own (unused for the pool layout) rank. Missing clients keep the old counting.