vgsp-sema: keep the scrubber release alive while the event pump blocks

The guest's PMA scrub wait and the host's status-queue pump can deadlock:
the X server's scrub wait holds the guest RM lock the status consumer
needs, the ring fills, and every critical event post then waits out its
full 200 ms ring-full budget. A service pass can take many seconds, so
the next pass's scrub step - the only thing that can release the scrub
wait - is starved and the guest never makes progress.

Run the scrub step from inside the send path's ring-full wait (service
thread only), and re-resolve the scrubber's finish/host-sema words on
every pass instead of once: the guest re-creates its RM kernel VAS and
re-maps the channel buffer under the same GPU VA (observed: gpfifo VA
0x120064000 moved from PA 0x127e6a000 to 0x1122e9000), so a once-only
resolution authored a page the guest no longer polled. Prefer the RM
kernel VAS (h=0xc) RAM mapping over a client VAS vidmem mapping, and
force re-resolution when a scrubber re-registers.

1 files changed, 9 insertions, 0 deletions

diff --git a/kernel/gsp_sema_service.h b/kernel/gsp_sema_service.h
index 8fec320..7228cd3 100644
--- a/kernel/gsp_sema_service.h
+++ b/kernel/gsp_sema_service.h
@@ -73,6 +73,15 @@ void gsp_sema_service_vgpu_cleanup(struct nv_vgpu_device *vgpu);
 int gsp_sema_service_scrubbuf_add(u64 fin_pa, u64 hsem_pa);
 
 /*
+ * Author the CeUtils scrubber's progress from the GSP-RM send path's
+ * ring-full wait loop (r1668). Called on the sema service thread only; it
+ * lets the scrub completion run while the pump is blocked posting a
+ * critical event into a status ring the guest cannot drain (the guest's RM
+ * consumer is frozen behind the very scrub wait this releases).
+ */
+void gsp_sema_service_scrub_pump(struct nv_vgpu_device *vgpu);
+
+/*
  * A GPU VA space whose top-level page directory the driver has published (the
  * driver builds its own page tables for the address spaces it owns, then hands
  * the directory's physical address to the GPU through SET_PAGE_DIRECTORY).