From: Joel Fernandes <joelagnelf@nvidia.com>
To: Timur Tabi <ttabi@nvidia.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>,
"dakr@kernel.org" <dakr@kernel.org>,
"lossin@kernel.org" <lossin@kernel.org>,
"a.hindborg@kernel.org" <a.hindborg@kernel.org>,
"boqun.feng@gmail.com" <boqun.feng@gmail.com>,
"ojeda@kernel.org" <ojeda@kernel.org>,
"simona@ffwll.ch" <simona@ffwll.ch>,
"tmgross@umich.edu" <tmgross@umich.edu>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"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>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"gary@garyguo.net" <gary@garyguo.net>,
Alistair Popple <apopple@nvidia.com>
Subject: Re: [PATCH 6/7] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command GSP upon unloading
Date: Thu, 18 Dec 2025 22:44:39 +0000 [thread overview]
Message-ID: <F72EBB64-BB07-4FFA-85C9-3EDE9AEE3C48@nvidia.com> (raw)
In-Reply-To: <1369611d0014a4e5b630462d66790939b0f564c0.camel@nvidia.com>
> On Dec 18, 2025, at 5:33 PM, Timur Tabi <ttabi@nvidia.com> wrote:
>
> On Thu, 2025-12-18 at 22:27 +0900, Alexandre Courbot wrote:
>>>> + loop {
>>>> + match cmdq.receive_msg::<UnloadingGuestDriverReply>(Delta::from_secs(5)) {
>>>> + Ok(resp) => return Ok(resp),
>>>> + Err(ERANGE) => continue,
>>>> + Err(e) => return Err(e),
>>>> + }
>>>
>>> This outer loop can go on infinitely, lets bound it?
>>>
>>> Either outer timeout or bounded number of tries. Bounded tries better since it has inner
>>> timeout.
>>
>> Yes. And what we really want is a more generic way to do this, because
>> this pattern occurs with several commands so far (and more to come).
>
> Isn't the real problem that we are polling for a specific message, when all message should be
> handled asynchronously as events, like Nouveau does?
>
> Err(ERANGE) => continue,
>
> This effectively throws out all other messages, including errors and anything else important.
>
Indeed, for that we need Interrupts. For the rest of the patterns where we need the message synchronously, we should bound this. Hanging in the driver is unacceptable.
Interrupts are almost here now, considering we/others have upstreamed all the required patches for Rust interrupt support.
next prev parent reply other threads:[~2025-12-18 22:44 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 [this message]
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
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=F72EBB64-BB07-4FFA-85C9-3EDE9AEE3C48@nvidia.com \
--to=joelagnelf@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--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=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