Re: [PATCH v2 09/15] gpu: nova-core: match GSP RPC replies by sequence, not just function

["Alexandre Courbot" <acourbot@nvidia.com>]

On Sat Aug 29, 2026 at 10:33 AM JST, John Hubbard wrote:
> The GSP replies to a command by echoing that command's function code and
> its RPC sequence number.
>
> nova-core matched replies on the function alone and never set the
> sequence, so a reply for a command that had already timed out could
> satisfy a later command using the same function.
>
> Give the RPC sequence its own counter, separate from the per-element
> transport sequence, set it on every command, and require both the
> function and the sequence to match before accepting a reply. A message
> with the expected function but a stale sequence is logged and dropped,
> not mistaken for the reply or dispatched as an event. A caller awaiting
> an unsolicited event still matches on the function alone.
>
> Assisted-by: Cursor:claude-opus-5
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>

So I am particularly looking at patches 8-11 at first, because it looks
like they can be merged ahead of the rest and are useful on their own,
but I am hitting an error with this one when unloading the driver:

modprobe -r nova-core
[ 3333.123171] nova-core 0000:08:00.0: GSP RPC: send: seq# 3, function=UnloadingGuestDriver, length=0x58
[ 3333.148123] nova-core 0000:08:00.0: GSP RPC: receive: seq# 0, function=Ok(GspPostNoCat), length=0x50c
[ 3333.169449] nova-core 0000:08:00.0: GSP RPC: receive: seq# 0, function=Ok(UcodeLibOsPrint), length=0x78
[ 3333.323550] nova-core 0000:08:00.0: GSP RPC: receive: seq# 0, function=Ok(UnloadingGuestDriver), length=0x50
[ 3333.323551] nova-core 0000:08:00.0: GSP RPC: dropping stale UnloadingGuestDriver reply (seq 0, awaiting Some(3))
[ 3338.124152] nova-core 0000:08:00.0: GSP shutdown failed: ETIMEDOUT
[ 3338.161317] nova-core 0000:08:00.0: failed to unload GSP: ETIMEDOUT

It looks like the GSP sends the UnloadingGuestDriver response with a
sequence of 0... From what I can gather from OpenRM, 570.144 doesn't
match the sequence number, only the function. Maybe this needs to be
part of the r000 series instead, if that behavior is only expected
there?