Nouveau - Sep 2025 - [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a dedicated method

On 9/13/25 1:37 PM, Miguel Ojeda wrote:
> On Sat, Sep 13, 2025 at 7:14?PM Joel Fernandes <joelagnelf at
nvidia.com> wrote:
>>
>> I am not alone in that opinion.
> 
> Hmm... I am not sure how to read this.
> 
>> This should be first-class in a (systems) language, built into
>> the language itself?
On this particular point, and *only* this point: some time around
mid-2025, I started wondering out loud, "shouldn't Rust have some
built-in understanding, in the language/compiler itself, of the
concept of pinned memory?"

Because, after doing a modest bit of Rust for Linux coding, I was
struck by "Rust is a systems programming langauge", vs. "systems
programming often involves DMA (which generally pins memory)".
And the other observation is that pin-init discussions are some
of the most advanced and exotic in Rust for Linux. These things
don't go together.

So it seemed like this is a lesson that Rust for Linux has learned,
that can be taken back to Rust itself. I recommended this as a
non-urgent Kangrejos topic.
> 
> I would suggest taking a look at our website and the links there (like
> issue #2) -- what we are doing upstream Rust is documented.
...and my question was asked before reading through issue #2. So your
and Danilo's responses seem to be saying that there is already some
understanding that this is an area that could be improved.

Good!

I believe "issue #2" refers to this, right?

    https://github.com/Rust-for-Linux/linux/issues/2

That's going to take some time to figure out if it interects
what I was requesting, but I'll have a go at it.
> 
> (Danilo gave you a direct link, but I mention it this way because
> there are a lot of things going on, and it is worth a look and perhaps
> you may find something interesting you could help with).
> 
>> except to satisfy paranoia
> 
> Using unsafe code everywhere (or introducing unsoundness or UB for
> convenience) would defeat much of the Rust for Linux exercise.
> 
Yes. It's only "paranoia" if the code is bug-free. So Rust itself
naturally will look "a little" paranoid, that's core to its
mission. :)


thanks,
-- 
John Hubbard

On Sat, Sep 13, 2025 at 02:29:54PM -0700, John Hubbard wrote:
[..]
> > 
> > I would suggest taking a look at our website and the links there (like
> > issue #2) -- what we are doing upstream Rust is documented.
> 
> ...and my question was asked before reading through issue #2. So your
> and Danilo's responses seem to be saying that there is already some
> understanding that this is an area that could be improved.
> 
> Good!
> 
> I believe "issue #2" refers to this, right?
> 
>    https://github.com/Rust-for-Linux/linux/issues/2
> 
> That's going to take some time to figure out if it interects
> what I was requesting, but I'll have a go at it.
Indeed, kudos to rust-for-linux community for working on missing Rust
features and on pinning itself.
> > 
> > (Danilo gave you a direct link, but I mention it this way because
> > there are a lot of things going on, and it is worth a look and perhaps
> > you may find something interesting you could help with).
> > 
> > > except to satisfy paranoia
> > 
> > Using unsafe code everywhere (or introducing unsoundness or UB for
> > convenience) would defeat much of the Rust for Linux exercise.
> > 
> 
> Yes. It's only "paranoia" if the code is bug-free. So Rust
itself
> naturally will look "a little" paranoid, that's core to its
mission. :)
This seems to be taken out-of-context, I said "paranoia" mainly
because I am
not sure if excessive use of pinning may tend to cause other problems. The
"paranoia" is about over-usage of pinning. Personally, I don't
prefer to pin
stuff in my code until I absolutely need to, or when I start having needs for
pinning, like using spinlocks. Maybe I am wrong, but the way I learnt Rust,
data movement is baked into it. I am not yet confident pinning will not
constraint Rust code gen -- but that could just be a part of my learning
journey that I have to convince myself it is Ok to do so in advance of
actually requiring it even if you simply hypothetically anticipate needing it
(as Danilo pointed out that in practice this is not an issue and I do tend to
agree with Miguel and Danilo because they are usually right :-D). I am
researching counter examples :-)

thanks,

 - Joel

On Sun Sep 14, 2025 at 7:06 AM JST, Joel Fernandes
wrote:
> On Sat, Sep 13, 2025 at 02:29:54PM -0700, John Hubbard wrote:
> [..]
>
>> > 
>> > I would suggest taking a look at our website and the links there
(like
>> > issue #2) -- what we are doing upstream Rust is documented.
>> 
>> ...and my question was asked before reading through issue #2. So your
>> and Danilo's responses seem to be saying that there is already some
>> understanding that this is an area that could be improved.
>> 
>> Good!
>> 
>> I believe "issue #2" refers to this, right?
>> 
>>    https://github.com/Rust-for-Linux/linux/issues/2
>> 
>> That's going to take some time to figure out if it interects
>> what I was requesting, but I'll have a go at it.
>
> Indeed, kudos to rust-for-linux community for working on missing Rust
> features and on pinning itself.
>
>> > 
>> > (Danilo gave you a direct link, but I mention it this way because
>> > there are a lot of things going on, and it is worth a look and
perhaps
>> > you may find something interesting you could help with).
>> > 
>> > > except to satisfy paranoia
>> > 
>> > Using unsafe code everywhere (or introducing unsoundness or UB for
>> > convenience) would defeat much of the Rust for Linux exercise.
>> > 
>> 
>> Yes. It's only "paranoia" if the code is bug-free. So
Rust itself
>> naturally will look "a little" paranoid, that's core to
its mission. :)
>
> This seems to be taken out-of-context, I said "paranoia" mainly
because I am
> not sure if excessive use of pinning may tend to cause other problems. The
> "paranoia" is about over-usage of pinning. Personally, I
don't prefer to pin
> stuff in my code until I absolutely need to, or when I start having needs
for
> pinning, like using spinlocks. Maybe I am wrong, but the way I learnt Rust,
> data movement is baked into it. I am not yet confident pinning will not
> constraint Rust code gen -- but that could just be a part of my learning
> journey that I have to convince myself it is Ok to do so in advance of
> actually requiring it even if you simply hypothetically anticipate needing
it
> (as Danilo pointed out that in practice this is not an issue and I do tend
to
> agree with Miguel and Danilo because they are usually right :-D). I am
> researching counter examples :-)
You can look at the definition for `Pin` in [1], but it is so short we
can paste it here:

    #[repr(transparent)]
    #[derive(Copy, Clone)]
    pub struct Pin<Ptr> {
        pointer: Ptr,
    }

There isn't much getting in the way of optimized code generation - its
purpose is simply to constraint the acquisition of mutable references to
prevent moving the pointee out.

I started this patchset a little bit skeptical about the need to pin so
many things, but after seeing the recent additions to `pin_init` and
rewriting the code as Danilo suggested, it starteds to click. The
supposed restrictions are in practice avoided by embracing the concept
fully, and in the end I got that feeling (familiar when writing Rust) of
being guided towards the right design - a bit like playing bowling with
gutter guards.

Yes, that means redesigning and rebasing our code, but that's also the
cost of learning a new language.

And yes, things can still be a little bit rough around the edges, but
there is awareness and action taken to address these issues, at the
compiler level when relevant. This makes me confident for the future.

[1] https://doc.rust-lang.org/src/core/pin.rs.html#1094