vgsp-rm: harden the boot-time queue link against the 4 s GspStatusQueueInit window

The guest's first RmInitAdapter intermittently fails: GspStatusQueueInit
gives the status-queue link only 4 s (message_queue_cpu.c: timeoutUs =
4000000) and the first boot attempt can burn it, after which the RM tears
down, leaks the device and retries; the surviving retry leaves the GR/ctx
state degraded, which is the persistent cudaMalloc stall class.

Changes:
- gsp_rm_emu_poll: parse-retry cadence 250 ms -> 50 ms (the 250 ms tick
  consumed a fifth of the guest's budget per attempt).
- gsp_rm_emu_reset: clear last_parse_retry so a new boot gets a fresh
  retry budget; take stat_lock while clearing queue cursors so a sema
  event post cannot race the reset.
- gsp_rm_emu_on_booter_done: on GSP_INIT_DONE send failure re-arm the
  retry path (parsed/active were already set, so the poll loop would
  never retry).
- gsp_rm_parse_queue_chain: free the previous ptes before re-alloc so
  retries and post-reset re-parses do not leak.
- gsp_rm_post_channel_event: never post events across a queue reset
  (parsed gate).

guest_kprobes.sh: add rpcs/rpcp transport probes (the direct RPC-wait
symbol is notrace in 570.144) and ccset entry/return probes for
rmapiControlCacheSet so a stall names the control whose reply breaks the
guest's control-cache bookkeeping.

0 files changed, 0 insertions, 0 deletions