[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DA9KIGDH4IF6.2T383ZVLTJN0G@nvidia.com>
Date: Fri, 30 May 2025 23:34:02 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Greg KH" <gregkh@...uxfoundation.org>
Cc: "Danilo Krummrich" <dakr@...nel.org>, "Timur Tabi" <timur@...nel.org>,
"John Hubbard" <jhubbard@...dia.com>, "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" <benno.lossin@...ton.me>,
"Andreas Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl"
<aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>,
<linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH] rust: add basic ELF sections parser
On Fri May 30, 2025 at 6:01 PM JST, Greg KH wrote:
> On Fri, May 30, 2025 at 03:59:03PM +0900, Alexandre Courbot wrote:
>> On Fri May 30, 2025 at 3:22 PM JST, Greg KH wrote:
>> > On Fri, May 30, 2025 at 09:58:02AM +0900, Alexandre Courbot wrote:
>> >> However, Nova also supports a couple of older chip generations that use
>> >> the same GSP firmware - it is for these that the ELF unpacking must
>> >> occur in the kernel. IIUC this has to do with the capabilities of the
>> >> microcontroller that ultimately does the loading (more capable RISC-V on
>> >> Hopper+ vs. older and more limited Falcon).
>> >
>> > Why specifically does the kernel have to get involved here? What
>> > requires it to do it that userspace can not?
>>
>> I don't know of a user-space tool that is readily available and could
>> perform such extraction of the ELF content upon kernel request. Is there
>> anything like this?
>
> libelf provides you with the needed tools for this.
>
> And you didn't answer my question.
Yes, extracting a section of an ELF file is as trivial as calling
objcopy, no issue with that.
What I don't understand is, who calls objcopy to do that in the first
place, when, and how is the extracted section passed to the kernel?
After digging a bit I found out about CONFIG_FW_LOADER_USER_HELPER which
looks like it could help, but that option is disabled even on my Arch
stock kernel.
But even assuming it was readily available, how to use it is not clear
to me and I could not find a single actual example. I assumed a udev
rule could catch the uevent and call a script that extracts the section
and load it through the sysfs loading interface, but
fallback-mechanisms.rst mentions that "...however firmware loading
support was removed from udev as of systemd commit be2ea723b1d0". Which
makes this idea look like a dead-end.
So to try to answer your question, I am not disagreeing that userspace
is capable of doing what we currently do in the kernel. My follow-up
questions to that are: how do we command userspace to do that work for
us when we request the firmware, how do we provide the result to the
kernel, and is this something that distros can adopt easily? I'm happy
to consider doing things this way, but would need a few pointers to look
into.
Powered by blists - more mailing lists