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().
