Re: [PATCH 6/7] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command GSP upon unloading

[Timur Tabi <ttabi@nvidia.com>]

On Fri, 2025-12-19 at 12:39 +0900, Alexandre Courbot wrote:



> Does Nouveau really handle all messages asynchronously? Just taking a
> look at `r535_gsp_rpc_send` I see:
> 
> * A potential busy-loop with `r535_gsp_rpc_handle_reply`, An argument to
> * define whether we should wait for a reply (`policy`).
> 
> So it seems like each GSP command expecting a reply is effectively
> looping until it arrives, with some messages (LIBOS_PRINT, SEQUENCER,
> etc.) being managed by a notifier registered with the command queue. But
> messages sent explicitly by the driver don't seem to make use of it and
> instead process messages until they find their reply.

Yes, you're right.  But the difference is that in Nouveau, all message processing is handled by
r535_gsp_msg_recv(), which always also handles all of the asynchronous "other" messages.

The above `loop` expression in Nova doesn't do that.  It's missing the asynchronous handler. 
This is the crux of my concern.

> This seems to work because IIUC the GSP sends replies in the same order
> as it received the messages (so one caller cannot consume the reply
> intended to another) and GSP messages are a replacement for the CPU
> messing with the hardware itself anyway. So in that context that design
> is not particularly awful, but maybe we will want to switch to something
> interrupt-based in Nova long-term anyway.

Sure, but we still need to do it the way Nouveau handles it.  We need our own version of
r535_gsp_rpc_handle_reply() which unifies handling of all incoming messages, either polling or
interrupt-based.

For now, we can always pass NVKM_GSP_RPC_REPLY_POLL or NVKM_GSP_RPC_REPLY_RECV, which are
polling-based.  NVKM_GSP_RPC_REPLY_NOWAIT is apparently interrupt-based, which I believe is
triggered via r535_gsp_msgq_work().