vgsp-sema r540: a denied transfer op keeps its slot incomplete past the pend cap

The r539 boot showed the 5-minute device-init stall class live: a GRCE
channel push (eng=0) carrying an H2D copy is decoded before the pin stream
reaches its operands, so allow_ops=0 and the copy is denied; the r308 path
sets op_tr_pending and holds the entry. That path is capped at 4 tries per
slot ('so a slot whose trust never arrives cannot wedge the channel'), but
once the cap is hit op_tr_pending stays 0 and svc_decode_stream's tail
marks the slot COMPLETE - so every later pass classifies the entry as a
replay and suppresses the copy forever. The pin arrives seconds later; the
copy still never runs and the client spins at DEVICE until UVM's own
retry. Evidence (r539, /tmp/opencode/r539-live.log): held idx 89/91..94 on
h=0x5c000059 with 'denied ... replay=1 trusted=1' and 'sema-pend: hold
... idx=89' for minutes while the client printed DEVICE.

Fix: new svc.op_owed flag. When the pend cap blocks the retry, the pass is
marked owed so slot_ops_complete stays 0; the next fresh pass runs the
copy as soon as the translation/injection exists. No hold is armed for an
owed pass, so an operand that never translates still cannot wedge the
pump (the denied path's liveness guarantee is preserved - only the
freshness is).

0 files changed, 0 insertions, 0 deletions