linux-kernel - Re: [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a dedicated method

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250913010226.GA1478480@joelbox2>
Date: Fri, 12 Sep 2025 21:02:26 -0400
From: Joel Fernandes <joelagnelf@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>
Cc: Danilo Krummrich <dakr@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	John Hubbard <jhubbard@...dia.com>,
	Alistair Popple <apopple@...dia.com>, Timur Tabi <ttabi@...dia.com>,
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
	nouveau@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a
 dedicated method

On Thu, Sep 11, 2025 at 10:26:08PM +0900, Alexandre Courbot wrote:
> On Thu Sep 11, 2025 at 9:46 PM JST, Danilo Krummrich wrote:
[..] 
> >> By keeping the initialization in the GPU, we can keep the GSP object
> >> architecture-independent, and I think it makes sense from a design point
> >> of view. That's not to say this code should be in `gpu.rs`, maybe we
> >> want to move it to a GPU HAL, or if we really want this as part of the
> >> GSP a `gsp/boot` module supporting all the different archs. But I'd
> >> prefer to think about this when we start supporting several
> >> architectures.
> >
> > Didn't we talk about a struct Gsp that will eventually be returned by
> > Self::start_gsp(), or did I make this up in my head?
> >
> > The way I think about this is that we'll have a struct Gsp that represents the
> > entry point in the driver to mess with the GSP command queue.
> >
> > But either way, this throws up two questions, if Self::start_gsp() return a
> > struct GspMemObjects instead (which is probably the same thing with a different
> > name), then:
> >
> > Are we sure this won't need any locks? If it will need locking (which I expect)
> > then it needs pin-init.
> 
> Sorry, I have been imprecise: I should I said: "it can be moved" rather
> than "it doesn't need to be pinned". In that case I don't think
> `Gsp::new` needs to return an `impl PinInit`, right?

If you don't mind clarifying for me, what is the difference between "it
doesn't need to be pinned" and "it can be moved"? AFAICS, they mean the same
thing. If you don't want move semantics on something, the only way to achieve
that is pinning no?. If it can be moved, and it contains locks, then that will
break unless pinned AFAICS. So if need locking in Gsp, which I think we'll
need (to support sychrnoized command queue accesses), then I think pinning is
unavoidable.

On the other hand, if just the firmware loading part is kept separate,
then perhaps that part can remain unpinned?

Any chance we can initialize the locks later? We don't need locking until
after the boot process is completed, and if there's a way we can dynamically
"pin", where we hypothetically pin after the boot process completed, that
might also work. Though I am not sure if that's something possible in
Rust/rust4linux or if it makes sense.

Other thoughts?

thanks,

 - Joel