On Fri, May 19, 2023 at 2:29 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Thu, May 18, 2023, at 17:38, Palmer Dabbelt wrote: > > On Thu, 18 May 2023 06:09:51 PDT (-0700), guoren@xxxxxxxxxx wrote: > >> From: Guo Ren <guoren@xxxxxxxxxxxxxxxxx> > >> > >> 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
