mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Greg KH" <gregkh@linuxfoundation.org>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
	"Timur Tabi" <timur@kernel.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH] rust: add basic ELF sections parser
Date: Fri, 30 May 2025 23:34:02 +0900	[thread overview]
Message-ID: <DA9KIGDH4IF6.2T383ZVLTJN0G@nvidia.com> (raw)
In-Reply-To: <2025053050-maggot-landfall-d5eb@gregkh>

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.

  reply	other threads:[~2025-05-30 14:34 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-15  6:03 Alexandre Courbot
2025-05-15  7:38 ` Greg KH
2025-05-15  8:32   ` Alexandre Courbot
2025-05-15 11:25     ` Alexandre Courbot
2025-05-15 11:42       ` Greg KH
2025-05-15 13:09         ` Alexandre Courbot
2025-05-15 14:30         ` Timur Tabi
2025-05-15 19:17           ` John Hubbard
2025-05-16 13:15             ` Greg KH
2025-05-16 13:26               ` Alexandre Courbot
2025-05-16 13:32                 ` Greg KH
2025-05-16 13:35                 ` Danilo Krummrich
2025-05-16 14:35                   ` Alexandre Courbot
2025-05-16 16:01                     ` Danilo Krummrich
2025-05-16 19:00                       ` John Hubbard
2025-05-17 10:13                         ` Danilo Krummrich
2025-05-17 13:41                           ` Alexandre Courbot
2025-05-16 16:28                     ` Timur Tabi
2025-05-17  0:51                       ` Alexandre Courbot
2025-05-29  6:53                         ` Alexandre Courbot
2025-05-29  8:01                           ` Greg KH
2025-05-30  0:58                             ` Alexandre Courbot
2025-05-30  6:21                               ` Greg KH
2025-05-30  6:56                                 ` Alexandre Courbot
2025-05-30  9:00                                   ` Greg KH
2025-05-30  6:22                               ` Greg KH
2025-05-30  6:59                                 ` Alexandre Courbot
2025-05-30  9:01                                   ` Greg KH
2025-05-30 14:34                                     ` Alexandre Courbot [this message]
2025-05-30 15:42                                       ` Greg KH
2025-05-30 18:10                                         ` Timur Tabi
2025-05-31  5:45                                           ` Greg KH
2025-05-31 10:17                                             ` Timur Tabi
2025-05-31 12:25                                               ` Greg KH
2025-05-31 14:38                                                 ` Timur Tabi
2025-05-31 15:28                                                   ` Danilo Krummrich
2025-06-01  7:48                                                   ` Greg KH
2025-05-31 12:33                                             ` Alexandre Courbot
2025-05-31 13:30                                               ` Greg KH
2025-06-01 12:23                                                 ` Alexandre Courbot
2025-06-13  3:32                                                 ` Alexandre Courbot
2025-06-24 14:26                                                   ` Greg KH
2025-06-24 14:51                                                     ` Danilo Krummrich

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=DA9KIGDH4IF6.2T383ZVLTJN0G@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=timur@kernel.org \
    --cc=tmgross@umich.edu \
    /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

all inboxes | Powered by JetHome®