lkml.org 
[lkml]   [2023]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH 00/22] riscv: s64ilp32: Running 32-bit Linux kernel on 64-bit supervisor mode
    On Fri, May 19, 2023 at 2:29 AM Arnd Bergmann <arnd@arndb.de> wrote:
    >
    > On Thu, May 18, 2023, at 17:38, Palmer Dabbelt wrote:
    > > On Thu, 18 May 2023 06:09:51 PDT (-0700), guoren@kernel.org wrote:
    > >> From: Guo Ren <guoren@linux.alibaba.com>
    > >>
    > >> This patch series adds s64ilp32 support to riscv. The term s64ilp32
    > >> means smode-xlen=64 and -mabi=ilp32 (ints, longs, and pointers are all
    > >> 32-bit), i.e., running 32-bit Linux kernel on pure 64-bit supervisor
    > >> mode. There have been many 64ilp32 abis existing, such as mips-n32 [1],
    > >> arm-aarch64ilp32 [2], and x86-x32 [3], but they are all about userspace.
    > >> Thus, this should be the first time running a 32-bit Linux kernel with
    > >> the 64ilp32 ABI at supervisor mode (If not, correct me).
    > >
    > > Does anyone actually want this? At a bare minimum we'd need to add it
    > > to the psABI, which would presumably also be required on the compiler
    > > side of things.
    > >
    > > It's not even clear anyone wants rv64/ilp32 in userspace, the kernel
    > > seems like it'd be even less widely used.
    >
    > We have had long discussions about supporting ilp32 userspace on
    > arm64, and I think almost everyone is glad we never merged it into
    > the mainline kernel, so we don't have to worry about supporting it
    > in the future. The cost of supporting an extra user space ABI
    > is huge, and I'm sure you don't want to go there. The other two
    > cited examples (mips-n32 and x86-x32) are pretty much unused now
    > as well, but still have a maintenance burden until they can finally
    > get removed.
    >
    > If for some crazy reason you'd still want the 64ilp32 ABI in user
    > space, running the kernel this way is probably still a bad idea,
    > but that one is less clear. There is clearly a small memory
    > penalty of running a 64-bit kernel for larger data structures
    > (page, inode, task_struct, ...) and vmlinux, and there is no
    I don't think it's a small memory penalty, our measurement is about
    16% with defconfig, see "Why 32-bit Linux?" section.
    This patch series doesn't add 64ilp32 userspace abi, but it seems you
    also don't like to run 32-bit Linux kernel on 64-bit hardware, right?

    The motivation of s64ilp32 (running 32-bit Linux kernel on 64-bit s-mode):
    - The target hardware (Canaan Kendryte k230) only supports MXL=64,
    SXL=64, UXL=64/32.
    - The 64-bit Linux + compat 32-bit app can't satisfy the 64/128MB scenarios.

    > huge additional maintenance cost on top of the ABI itself
    > that you'd need either way, but using a 64-bit address space
    > in the kernel has some important advantages even when running
    > 32-bit userland: processes can use the entire 4GB virtual
    > space, while the kernel can address more than 768MB of lowmem,
    > and KASLR has more bits to work with for randomization. On
    > RISCV, some additional features (VMAP_STACK, KASAN, KFENCE,
    > ...) depend on 64-bit kernels even though they don't
    > strictly need that.

    I agree that the 64-bit linux kernel has more functionalities, but:
    - What do you think about linux on a 64/128MB SoC? Could it be
    affordable to VMAP_STACK, KASAN, KFENCE?
    - I think 32-bit Linux & RTOS have monopolized this market (64/128MB
    scenarios), right?

    >
    > Arnd



    --
    Best Regards
    Guo Ren

    \
     
     \ /
      Last update: 2023-05-19 17:31    [W:4.495 / U:0.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site