Rust for Linux List
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "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>
Subject: Re: [PATCH v5 7/7] gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbinding
Date: Thu, 21 May 2026 20:03:42 +0900	[thread overview]
Message-ID: <DIOAZCL9W7F7.J3WV406BXTY8@nvidia.com> (raw)
In-Reply-To: <DIMAVKJECLKH.UXLZASCKVJK0@nvidia.com>

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.

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!

  parent reply	other threads:[~2026-05-21 11:03 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 [this message]
2026-05-21 13:04       ` Eliot Courtney

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=DIOAZCL9W7F7.J3WV406BXTY8@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ecourtney@nvidia.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox