linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: gerg@kernel.org, damien.lemoal@opensource.wdc.com, macro@orcam.me.uk
Cc: linux-riscv@lists.infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] riscv: support ELF format binaries in nommu mode
Date: Tue, 14 Mar 2023 20:58:32 -0700 (PDT)	[thread overview]
Message-ID: <mhng-a62a57b8-4268-4c51-b79e-f5f6bd0c13a2@palmer-ri-x1c9a> (raw)
In-Reply-To: <d641459e-c52b-c42e-dfcb-77bb978414f8@kernel.org>

On Tue, 28 Feb 2023 16:20:35 PST (-0800), gerg@kernel.org wrote:
> Hi Palmer,
>
> On 1/3/23 07:52, Palmer Dabbelt wrote:
>> On Tue, 28 Feb 2023 05:51:24 PST (-0800), gerg@kernel.org wrote:
>>> The following changes add the ability to run ELF format binaries when
>>> running RISC-V in nommu mode. That support is actually part of the
>>> ELF-FDPIC loader, so these changes are all about making that work on
>>> RISC-V.
>>>
>>> The first issue to deal with is making the ELF-FDPIC loader capable of
>>> handling 64-bit ELF files. As coded right now it only supports 32-bit
>>> ELF files.
>>>
>>> Secondly some changes are required to enable and compile the ELF-FDPIC
>>> loader on RISC-V and to pass the ELF-FDPIC mapping addresses through to
>>> user space when execing the new program.
>>>
>>> These changes have not been used to run actual ELF-FDPIC binaries.
>>> It is used to load and run normal ELF - compiled -pie format. Though the
>>> underlying changes are expected to work with full ELF-FDPIC binaries if
>>> or when that is supported on RISC-V in gcc.
>>>
>>> To avoid needing changes to the C-library (tested with uClibc-ng
>>> currently) there is a simple runtime dynamic loader (interpreter)
>>> available to do the final relocations, https://github.com/gregungerer/uldso.
>>> The nice thing about doing it this way is that the same program
>>> binary can also be loaded with the usual ELF loader in MMU linux.
>>>
>>> The motivation here is to provide an easy to use alternative to the
>>> flat format binaries normally used for RISC-V nommu based systems.
>>>
>>> Signed-off-by: Greg Ungerer <gerg@kernel.org>
>>> ---
>>>
>>>  arch/riscv/include/asm/elf.h         |   11 +++++++++-
>>>  arch/riscv/include/asm/mmu.h         |    4 +++
>>>  arch/riscv/include/uapi/asm/ptrace.h |    5 ++++
>>>  fs/Kconfig.binfmt                    |    2 -
>>>  fs/binfmt_elf_fdpic.c                |   38 +++++++++++++++++------------------
>>>  include/linux/elf-fdpic.h            |   14 +++++++++++-
>>>  include/uapi/linux/elf-fdpic.h       |   15 +++++++++++++
>>>  7 files changed, 67 insertions(+), 22 deletions(-)
>>
>> Adding Damien, as IIRC he's had some hacked up userspace bits for the K210.  I'm yet to get anything running, but it'd be great if we get this to a point where I can actually boot test this on QEMU (I'm just doing builds now).
>
> This is a simple script I user to generate a working QEMU example:
>
>    https://raw.githubusercontent.com/gregungerer/simple-linux/master/build-riscvnommu-linux-uclibc-elf.sh
>
> It does reference some configs here https://github.com/gregungerer/simple-linux/tree/master/configs
> and this posted patchset as https://github.com/gregungerer/simple-linux/tree/master/patches (this is
> just these 2 patches combined as a single patch).
>
>
>> Given that it's the second week of the merge window and this is a bunch of new uABI it seems best to hold off until the next cycle.  I poked around and don't see anything wrong, but I'll try and take a more detailed look after the merge window.
>
> Oh, yeah, no hurry.

Maciej and Damien: I'm fine taking this, but not in any rush.  I'd 
rather get the uABI right if things are still in flight, but if we're 
all just waiting for something to get merged first then I'm fine with 
that being Linux.

>
> Regards
> Greg


  reply	other threads:[~2023-03-15  3:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-28 13:51 Greg Ungerer
2023-02-28 13:51 ` [PATCH 1/2] binfmt_elf_fdpic: support 64-bit systems Greg Ungerer
2023-03-21 22:49   ` Palmer Dabbelt
2023-03-29 13:48     ` Greg Ungerer
2023-04-19  3:27       ` Palmer Dabbelt
2023-04-20 14:58         ` Greg Ungerer
2023-07-10 23:18           ` Palmer Dabbelt
2023-07-11 11:53             ` Greg Ungerer
2023-02-28 13:51 ` [PATCH 2/2] riscv: support the elf-fdpic binfmt loader Greg Ungerer
2023-02-28 21:52 ` [PATCH 0/2] riscv: support ELF format binaries in nommu mode Palmer Dabbelt
2023-02-28 22:44   ` Maciej W. Rozycki
2023-02-28 22:49   ` Damien Le Moal
2023-03-01  0:24     ` Greg Ungerer
2023-03-01  1:14       ` Damien Le Moal
2023-03-01  9:46     ` Niklas Cassel
2023-03-01  0:20   ` Greg Ungerer
2023-03-15  3:58     ` Palmer Dabbelt [this message]
2023-03-15  4:12       ` Damien Le Moal

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=mhng-a62a57b8-4268-4c51-b79e-f5f6bd0c13a2@palmer-ri-x1c9a \
    --to=palmer@dabbelt.com \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=gerg@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=macro@orcam.me.uk \
    /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