Re: [PATCH v4 06/10] gpu: nova-core: gsp: cmdq: move RPC message logging to RpcMessage

["Eliot Courtney" <ecourtney@nvidia.com>]

On Fri Oct 9, 2026 at 8:54 PM JST, Alexandre Courbot wrote:
> The `RpcMessage` type is the right container for the `log_event` method,
> since it contains all the data we passed to it. Move it there so callers
> don't need to extract the required data themselves.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
[...]
> -            let function = rpc_msg.header.function();
> -            let seq = rpc_msg.header.sequence();
> +
> +            RpcMessage::parse(self.dev, msg)?.log(self.dev);

nit: in core/interrupts.rst we say:

``` A drain fails when a message's framing or checksum is bad (see
"Draining the GSP-to-CPU queue"). The message stays at the queue head,
so every later drain would fail the same way, and the IRQ thread
disables vector 155 and logs the failure, which leaves the queue
unserviced until the device is reset. ```

So `parse()?` returning early on failure here is intentional, but I
reckon it is worth a comment, especially since the behaviour is
different to the semantics for consuming elements regularly (still
consumes and progresses for failed elements). Especially since you
wouldn't expect this behaviour to differ for a method which explicitly
"consumes every message the queue holds".

It looks like this is acting as some kind of implicit poisoning.

>              self.gsp_mem.advance_cpu_read_ptr(pages);
> -            self.log_event(function, seq);
>          }
>  
>          Ok(())