From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>, <nova-gpu@lists.linux.dev>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<rust-for-linux@vger.kernel.org>,
"dri-devel" <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH v5 7/7] gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbinding
Date: Thu, 21 May 2026 22:04:58 +0900 [thread overview]
Message-ID: <DIODK73THOGE.EROPFHMO2YHK@nvidia.com> (raw)
In-Reply-To: <DIOAZCL9W7F7.J3WV406BXTY8@nvidia.com>
On Thu May 21, 2026 at 8:03 PM JST, Alexandre Courbot wrote:
> Hi Eliot,
>
> On Tue May 19, 2026 at 11:33 AM JST, Eliot Courtney wrote:
>>>
>>> + // With the GSP shut down, reset the GSP so it can be restarted.
>>> + if let Some(unload_bundle) = self.unload.as_ref() {
>>> + unload_bundle.run(dev, bar, gsp_falcon, sec2_falcon)?;
>>> + } else {
>>> + dev_warn!(
>>> + dev,
>>> + "Unload bundle is missing, GSP won't be properly reset.\n"
>>> + );
>>> + }
>>
>> It feels a bit odd to me to (conceptually) allow the unload bundle to be
>> run multiple times. IMO, ideally we would be able to take() this. Since
>> we don't have a mut self though we can't unless we add a Mutex or
>> something. If we do, we can update UnloadBundle::run to consume the
>> value so it can only be run once, which is nice. WDYT?
>
> I'm a bit on the fence. On the one hand yes, we typically want the
> unload bundle to be run only once. On the other hand, we can also
> imagine than `unload` fails for some reason (say, the GSP refused to
> shut down when asked), and the driver decides to try again sometime
> later. It's not what we do now, but doing so would technically not be
> incorrect.
>
> I would feel strongly about enforcing single-shot use if this had safety
> implications, but here it is just to enforce something that is already
> structurally guaranteed by the driver core and that, in the worst case,
> returns a runtime error. IIUC `boot` has the same problem as well - it
> can be called even after the GSP is booted, it would just fail pretty
> early.
>
> With that in mind, I am not sure it is worth introducing a `Mutex` just
> for that. We could also use a `Cell` as of now, but since `Gsp` will
> probably need to be `Sync` soon that also won't work too well.
Yerp I think that is very fair, I was hoping you would know some better
way to do this than what I could come up with. If not I think the
current way is okay.
>
> But there is another option: store the `UnloadBundle` into `NovaCore`,
> and make `NovaCoreDriver::unbind` pass it to `Gpu::unbind` and by
> transition to Gsp::unload` as an argument. This would address the issue
> partially, as now unloading can only be initiated by the driver. And
> here we should be able to use `Cell` as `NovaCore` doesn't need to be
> `Sync`, and implement single-shot logic without a `Mutex`.
>
> The drawback being that this complicates `Gpu::new` a bit, as the unload
> bundle would now need to be passed as a `& mut` reference to be written
> to, i.e. an output argument which is not super idiomatic to do imho. But
> I'll give it a try to see how it looks.
>
> I've addressed all the other comments, thanks for the review!
prev parent reply other threads:[~2026-05-21 13:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-15 6:12 [PATCH v5 0/7] gpu: nova-core: run unload sequence upon unbinding Alexandre Courbot
2026-05-15 6:12 ` [PATCH v5 1/7] gpu: nova-core: remove unneeded get_gsp_info proxy function Alexandre Courbot
2026-05-15 6:12 ` [PATCH v5 2/7] gpu: nova-core: do not import firmware commands into GSP command module Alexandre Courbot
2026-05-15 6:12 ` [PATCH v5 3/7] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command upon unloading Alexandre Courbot
2026-05-15 6:12 ` [PATCH v5 4/7] gpu: nova-core: refactor SEC2 booter loading into BooterFirmware::run() Alexandre Courbot
2026-05-15 6:12 ` [PATCH v5 5/7] gpu: nova-core: gsp: shuffle boot code a bit to keep chipset-specific parts close Alexandre Courbot
2026-05-15 6:12 ` [PATCH v5 6/7] gpu: nova-core: gsp: move chipset-specific parts of the boot process into a HAL Alexandre Courbot
2026-05-19 1:32 ` Eliot Courtney
2026-05-15 6:12 ` [PATCH v5 7/7] gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbinding Alexandre Courbot
2026-05-19 2:33 ` Eliot Courtney
2026-05-19 2:42 ` John Hubbard
2026-05-21 11:03 ` Alexandre Courbot
2026-05-21 13:04 ` Eliot Courtney [this message]
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=DIODK73THOGE.EROPFHMO2YHK@nvidia.com \
--to=ecourtney@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel-bounces@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.