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

["Alexandre Courbot" <acourbot@nvidia.com>]

On Sun Sep 14, 2025 at 11:42 PM JST, Benno Lossin wrote:
> On Sun Sep 14, 2025 at 3:49 AM CEST, Alexandre Courbot wrote:
>> 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:
>>>> 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.
>
> That's a great way to put it -- I had a similar experience when writing
> pin-init and thinking about it purely theoretically. Good to see that it
> works out in practice (and continues to do so :).
>
>> 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.
>
> If you have an issue that you cannot work around, or something that
> looks off, let me know. Maybe that's something that pin-init can deal
> better with or we can have another library that helps with it. After all
> pin-init is specially tailored for the kernel to work :)

I was thinking about the lack of access to already-initialized fields in
the initializer when writing this, which has been covered so thanks for
that. :)

One more thing I still don't know how to do without unsafe code is
accessing structurally-pinned members of a pinned object. I had expected
that projection methods would be generated for such members marked
`#[pin]`, but I haven't found anything yet. For instance, we need to
call mutable methods on a pinned member of a pinned object, and the only
way I have found to do this is to use unsafe code. Is there a better
way?