From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Timur Tabi" <ttabi@nvidia.com>
Cc: "Joel Fernandes" <joelagnelf@nvidia.com>,
"gary@garyguo.net" <gary@garyguo.net>,
"lossin@kernel.org" <lossin@kernel.org>,
"ojeda@kernel.org" <ojeda@kernel.org>,
"boqun.feng@gmail.com" <boqun.feng@gmail.com>,
"a.hindborg@kernel.org" <a.hindborg@kernel.org>,
"simona@ffwll.ch" <simona@ffwll.ch>,
"tmgross@umich.edu" <tmgross@umich.edu>,
"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>,
"bjorn3_gh@protonmail.com" <bjorn3_gh@protonmail.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"aliceryhl@google.com" <aliceryhl@google.com>,
"kwilczynski@kernel.org" <kwilczynski@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"dakr@kernel.org" <dakr@kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"Alistair Popple" <apopple@nvidia.com>
Subject: Re: [PATCH 6/7] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command GSP upon unloading
Date: Wed, 14 Jan 2026 23:02:51 +0900 [thread overview]
Message-ID: <DFOD9BX2FHP2.X5ST15IMUR1G@nvidia.com> (raw)
In-Reply-To: <64be6d1f5fd70c8f0e3988d4220212b9f3d1d418.camel@nvidia.com>
On Sun Dec 21, 2025 at 6:30 AM JST, Timur Tabi wrote:
> 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.
I agree with you that this is something we want to improve (either by
adding a handler to the loop, or some other way). It should be its own
patch series once we have better visibility about how we want to handle
message, as the current implementation is still very crude and ad-hoc.
next prev parent reply other threads:[~2026-01-14 14:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-16 5:13 [PATCH 0/7] gpu: nova-core: run unload sequence upon unbinding Alexandre Courbot
2025-12-16 5:13 ` [PATCH 1/7] rust: pci: pass driver data by value to `unbind` Alexandre Courbot
2025-12-16 12:14 ` Danilo Krummrich
2025-12-16 14:38 ` Alexandre Courbot
2025-12-16 5:13 ` [PATCH 2/7] rust: add warn_on_err macro Alexandre Courbot
2025-12-16 5:13 ` [PATCH 3/7] gpu: nova-core: use " Alexandre Courbot
2025-12-16 5:13 ` [PATCH RFC 4/7] rust: pin-init: allow `dead_code` on projection structure Alexandre Courbot
2025-12-16 6:12 ` Benno Lossin
2025-12-16 5:13 ` [PATCH 5/7] gpu: nova-nova: use pin-init projections Alexandre Courbot
2025-12-16 5:13 ` [PATCH 6/7] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command GSP upon unloading Alexandre Courbot
2025-12-16 15:39 ` Joel Fernandes
2025-12-18 13:27 ` Alexandre Courbot
2025-12-18 20:52 ` Joel Fernandes
2025-12-19 3:26 ` Alexandre Courbot
2025-12-19 6:42 ` Joel Fernandes
2025-12-18 22:33 ` Timur Tabi
2025-12-18 22:44 ` Joel Fernandes
2025-12-18 23:34 ` Timur Tabi
2025-12-19 1:46 ` Joel Fernandes
2025-12-19 1:48 ` Joel Fernandes
2025-12-19 3:39 ` Alexandre Courbot
2025-12-20 21:30 ` Timur Tabi
2026-01-14 14:02 ` Alexandre Courbot [this message]
2025-12-16 5:13 ` [PATCH 7/7] gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbinding Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DFOD9BX2FHP2.X5ST15IMUR1G@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=joelagnelf@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox