lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZVGkk3Bps5eF5+BZ@gmail.com>
Date:   Sun, 12 Nov 2023 23:22:43 -0500
From:   Guo Ren <guoren@...nel.org>
To:     arnd@...db.de, palmer@...osinc.com, tglx@...utronix.de,
        conor.dooley@...rochip.com, heiko@...ech.de,
        apatel@...tanamicro.com, atishp@...shpatra.org, bjorn@...nel.org,
        paul.walmsley@...ive.com, anup@...infault.org, jiawei@...as.ac.cn,
        liweiwei@...as.ac.cn, wefu@...hat.com, U2FsdGVkX1@...il.com,
        wangjunqiang@...as.ac.cn, kito.cheng@...ive.com,
        andy.chiu@...ive.com, vincent.chen@...ive.com,
        greentime.hu@...ive.com, wuwei2016@...as.ac.cn, jrtc27@...c27.com,
        luto@...nel.org, fweimer@...hat.com, catalin.marinas@....com,
        hjl.tools@...il.com
Cc:     linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org, Guo Ren <guoren@...ux.alibaba.com>
Subject: Re: [RFC PATCH V2 00/38] rv64ilp32: Running ILP32 on RV64 ISA

On Sun, Nov 12, 2023 at 01:14:36AM -0500, guoren@...nel.org wrote:
> From: Guo Ren <guoren@...ux.alibaba.com>
> 
> This patch series adds s64ilp32 & u64ilp32 support to riscv. The term
> s64ilp32 means smode-xlen=64 and -mabi=ilp32 (ints, longs, and pointers
> are all 32-bit) and u64ilp32 means umode-xlen=64 and -mabi=ilp32, i.e.,
> running 32-bit Linux kernel on 64-bit supervisor mode or running 32-bit
> Linux applications on 32-bit user 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).
> 
>  +--------------------------------+------------+
>  | +-------------------+--------+ | +--------+ |
>  | |           (compat)|(compat)| | |        | |
>  | |u64lp64    u64ilp32|u32ilp32| | |u32ilp32| | ABI
>  | |           ^^^^^^^^|        | | |        | |
>  | +-------------------+--------+ | +--------+ |
>  | +-------------------+--------+ | +--------+ |
>  | |       UXL=64      | UXL=32 | | | UXL=32 | | ISA
>  | +-------------------+--------+ | +--------+ |
>  +--------------------------------+------------+-------
>  | +----------------------------+ | +--------+ |
>  | |            64BIT           | | |   32BIT| | Kernel
>  | |     s64lp64 & s64ilp32     | | |s32ilp32| | ABI
>  | |               ^^^^^^^^     | | |        | |
>  | +----------------------------+ | +--------+ |
>  | +----------------------------+ | +--------+ |
>  | |            SXL=64          | | | SXL=32 | | ISA
>  | +----------------------------+ | +--------+ |
>  +--------------------------------+------------+
> 
> Motivation:
> ===========
> The current RISC-V has the 64-bit ISA profiles of RVA20, RVA22, and RVA23
> (ongoing) [4], but no 32-bit RVA profile exists or any ongoing plan. That
> means when a vendor wants to produce a 32-bit ISA RISC-V Application
> Processor, they have no shape to follow. Therefore, many cheap riscv
> chips have come out but follow the 64-bit RVA profiles, such as Allwinner
> D1/D1s/F133 [5], SOPHGO CV1800B [6], Canaan Kendryte k230 [7], and
> Bouffalo Lab BL808[3] which are typically cortex-a7 (arm 32-bit) product
> scenarios. So running ILP32 on rv64 ISA is the only choice for these
> chips.
> 
> The ilp32 and lp64 have different scenarios, but if the address space
> and data range are under 2GB. The ilp32, compared to the lp64, has three
> advantages:
>  - Better memory footprint cost.
>  - Better benchmark performance (SPEC CPU 2006/2017).
>  - Compatible with ilp32 code.
> 
> Memory Footprint
> ================
> rv64lp64 has 25% more memory footprint than rv64ilp32!
> 
> Calculation Process:
>  rv64lp64  = (4096 - 3407) = 689
>  rv64ilp32 = (4096 - 3231) = 865
Correct:
   rv64ilp32 = (4096 - 3407) = 689
   rv64lp64  = (4096 - 3231) = 865

>  (865 - 689)/689 = 25.54426%
> 
> Here are the ILP32 v.s. LP64 Linux kernel data type comparison:
> 			32-bit		64-bit
> sizeof(page):		32bytes		64bytes
> sizeof(list_head):	8bytes		16bytes
> sizeof(hlist_head):	8bytes		16bytes
> sizeof(vm_area):	68bytes		136bytes
> ...
> 
> The size of ilp32's long & pointer is just half of lp64's (rv64 default
> abi - longs and pointers are all 64-bit). This significant difference
> in data type causes different memory & cache footprint costs. Here is
> the comparison log between rv64ilp32 and rv64lp64 in the same 20MB(16MB
> for Linux) qemu system environment:
> 
> rv64ilp32:
>  Memory: 14008K/16384K available (1253K kernel code, 474K rwdata, 114K
>  rodata, 134K init, 192K bss, 2376K reserved, 0K cma-reserved)
>  Mem-Info:
>  active_anon:0 inactive_anon:0 isolated_anon:0
>   active_file:0 inactive_file:0 isolated_file:0
>   unevictable:0 dirty:0 writeback:0
>   slab_reclaimable:0 slab_unreclaimable:47
>   mapped:0 shmem:0 pagetables:0
>   sec_pagetables:0 bounce:0
>   kernel_misc_reclaimable:0
>   free:3407 free_pcp:45 free_cma:0
>   ^^^^^^^^^
>  Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB
>  inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
>  mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB
>  kernel_stack:104kB pagetables:0kB sec_pagetabl
>  es:0kB all_unreclaimable? no
>  Normal free:13628kB boost:0kB min:472kB low:588kB high:704kB
>  reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>  active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>  present:16384kB managed:14140kB mlocked:0kB bounce:0
>  kB free_pcp:180kB local_pcp:180kB free_cma:0kB
>  lowmem_reserve[]: 0 0
>  Normal: 3*4kB (UM) 2*8kB (M) 2*16kB (M) 2*32kB (M) 3*64kB (M) 2*128kB
>  (UM) 3*256kB (M) 4*512kB (UM) 2*1024kB (UM) 2*2048kB (UM) 1*4096kB (M) =
>  13628kB
>  0 total pagecache pages
>  4096 pages RAM
>  0 pages HighMem/MovableOnly
>  561 pages reserved
> 
> rv64lp64:
>  Memory: 13776K/16384K available (1234K kernel code, 539K rwdata, 129K
>  rodata, 161K init, 207K bss, 2608K reserved, 0K cma-reserved)
>  Mem-Info:
>  active_anon:0 inactive_anon:0 isolated_anon:0
>   active_file:0 inactive_file:0 isolated_file:0
>   unevictable:0 dirty:0 writeback:0
>   slab_reclaimable:0 slab_unreclaimable:69
>   mapped:0 shmem:0 pagetables:1
>   sec_pagetables:0 bounce:0
>   kernel_misc_reclaimable:0
>   free:3231 free_pcp:55 free_cma:0
>   ^^^^^^^^^
>  Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB
>  inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
>  mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB
>  kernel_stack:208kB pagetables:4kB sec_pagetabl
>  es:0kB all_unreclaimable? no
>  Normal free:12924kB boost:0kB min:468kB low:584kB high:700kB
>  reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>  active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>  present:16384kB managed:13936kB mlocked:0kB bounce:0
>  kB free_pcp:220kB local_pcp:220kB free_cma:0kB
>  lowmem_reserve[]: 0 0
>  Normal: 3*4kB (UM) 4*8kB (UM) 3*16kB (M) 3*32kB (UM) 1*64kB (M) 3*128kB
>  (UM) 2*256kB (M) 3*512kB (M) 2*1024kB (UM) 2*2048kB (UM) 1*4096kB (M) =
>  12924kB
>  0 total pagecache pages
>  4096 pages RAM
>  0 pages HighMem/MovableOnly
>  612 pages reserved
> 
> Why rv64 isa?
> ==============
> Generally speaking, we should build a 32-bit hardware s-mode to run
> 32-bit Linux on a 64/32-bit processor (such as cortex-a35/a53).
> But, it can't reuse performance-related features and instructions of
> the 64-bit hardware, such as 64-bit ALU, AMO, and LD/SD, which would
> cause significant performance gaps on many Linux kernel features:
> 
>  - memcpy/memset/strcmp (s64ilp32 has half of the instructions count
>    and double the bandwidth of load/store instructions than s32ilp32.)
> 
>  - ebpf JIT is a 64-bit Language virtual machine ISA, which is not
>    suitable for mapping to s32ilp32.
> 
>  - Atomic64 (s64ilp32 has the exact native instructions mapping as
>    s64lp64, but s32ilp32 only uses generic_atomic64, a tradeoff &
>    limited software solution.)
> 
>  - Support cmxchg_double for slub (The 2nd 32-bit Linux
>    supports the feature, the 1st is i386.)
> 
>  - ...
> 
> Compared with the user space ecosystem, the 32-bit Linux kernel is more
> eager to need 64ilp32 to improve performance because the Linux kernel
> can't utilize float-point/vector features of the ISA.
> 
> Simplifies CPU Design
> =====================
> Yes, there are a lot of runing 32-bit Linux on 64-bit hardware examples
> in history, such as arm cortex a35/a53/a55, which implements the 32-bit
> EL1/EL2/EL3 hardware mode to support 32-bit Linux. We could follow Arm's
> style, but riscv could choose another better way. Compared to UXL=32,
> the MXL=SXL=32 has many CSR-related hardware functionalities, which
> causes a lot of effort to mix them into 64-bit hardware. The s64ilp32
> works on MXL=SXL=64 mode, so the CPU vendors needn't implement 32-bit
> machine and supervisor modes.
> 
> How does rv64ilp32 work?
> ========================
> The s64ilp32 is the same as the s64lp64 compat mode from a hardware
> view, i.e., MXL=SXL=64 + UXL=32. Because the s64ilp32 uses CONFIG_32BIT
> of Linux, it only supports u32ilp32 abi user space, the current standard
> rv32 software ecosystem, and it can't work with u64lp64 abi (I don't
> want that complex and useless stuff). But it may work with u64ilp32 in the
> future; now, the s64ilp32 depends on the UXL=32 feature of the hardware.
> 
> The 64ilp32 gcc still uses sign-extend lw & auipc to generate address
> variables because inserting zero-extend instructions to mask the highest
> 32-bit would cause significant code size and performance problems. Thus,
> we invented an OS approach to solve the problem:
>  - When satp=bare and start physical address < 2GB, there is no sign-extend
>    address problem.
>  - When satp=bare and start physical address > 2GB, we need zjpm liked
>    hardware extensions to mask high 32bit.
>    (Fortunately, all existed SoCs' (D1/D1s/F133, CV1800B, k230, BL808)
>     start physical address < 2GB.)
>  - When satp=sv39, we invent double mapping to make the sign-extended
>    virtual address the same as the zero-extended virtual address.
> 
>    +--------+      +---------+      +--------+
>    |        |   +--| 511:PUD1|      |        |
>    |        |   |  +---------+      |        |
>    |        |   |  | 510:PUD0|--+   |        |
>    |        |   |  +---------+  |   |        |
>    |        |   |  |         |  |   |        |
>    |        |   |  |         |  |   |        |
>    |        |   |  |         |  |   |        |
>    |        |   |  | INVALID |  |   |        |
>    |        |   |  |         |  |   |        |
>    |  ....  |   |  |         |  |   |  ....  |
>    |        |   |  |         |  |   |        |
>    |        |   |  +---------+  |   |        |
>    |        |   +--|  3:PUD1 |  |   |        |
>    |        |   |  +---------+  |   |        |
>    |        |   |  |  2:PUD0 |--+   |        |
>    |        |   |  +---------+  |   |        |
>    |        |   |  |1:USR_PUD|  |   |        |
>    |        |   |  +---------+  |   |        |
>    |        |   |  |0:USR_PUD|  |   |        |
>    +--------+<--+  +---------+  +-->+--------+
>       PUD1         ^   PGD             PUD0 
>       1GB          |   4GB             1GB
>                    |
>                    +----------+      
>                    | Sv39 PGDP|
>                    +----------+      
>                        SATP
> 
> The size of xlen was always equal to the pointer/long size before
> s64ilp32 emerged. So we need to introduce a new type of data - xlen_t,
> which could deal with CSR-related and callee-save/restore operations.
> 
> Some kernel features use 32BIT/64BIT to determine the exact ISA, such as
> ebpf JIT would map to rv32 ISA when CONFIG_32BIT=y. But s64ilp32 needs
> the ebpf JIT map to rv64 ISA when CONFIG_32BIT=y and we need to use
> another config to distinguish the difference.
> 
> More detials, please review the path series.
> 
> How to run s64ilp32?
> ====================
> 
> GNU toolchain
> -------------
> git clone https://github.com/Liaoshihua/riscv-gnu-toolchain.git
> cd riscv-gnu-toolchain
> ./configure --prefix="$PWD/opt-rv64-ilp32/" --with-arch=rv64imac --with-abi=ilp32
> make linux
> export PATH=$PATH:$PWD/opt-rv64-ilp32/bin/
> 
> Opensbi
> -------
> git clone https://github.com/riscv-software-src/opensbi.git
> CROSS_COMPILE=riscv64-unknown-linux-gnu- make PLATFORM=generic
> 
> Linux kernel
> ------------
> v6.5-rc1 + patches
> cd linux
> make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- rv64ilp32_defconfig
> make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- all
> 
> Qemu
> ----
> git clone https://github.com/plctlab/plct-qemu.git -b plct-s64ilp32-dev
> cd plct-qemu
> mkdir build
> cd build
> ../qemu/configure --target-list="riscv64-softmmu riscv32-softmmu"
> make
> 
> Patch organization
> ==================
> PATCH [ 1-11] u64ilp32: User space support
> PATCH [12-36] adds time-related vDSO common flow for vdso32
Correct:
  PATCH [12-36] s64ilp32: Add 64ilp32 linux kernel support2
> PATCH [37] Add tiny defconfig for ilp32 v.s. lp64
> PATCH [38] Unify ilp32 & lp64 configs and memory 
> 
> Open issues
> ===========
> 
> Callee saved the register width
> -------------------------------
> For 64-bit ISA (including 64lp64, 64ilp32), callee can't determine the
> correct width used in the register, so they saved the maximum width of
> the ISA register, i.e., xlen size. We also found this rule in x86-x32,
> mips-n32, and aarch64ilp32, which comes from 64lp64. See PATCH [20]
> 
> Here are two downsides of this:
>  - It would cause a difference with 32ilp32's stack frame, and s64ilp32
>    reuses 32ilp32 software stack. Thus, many additional compatible
>    problems would happen during the porting of 64ilp32 software.
>  - It also increases the budget of the stack usage.
>    <setup_vm>:
>      auipc   a3,0xff3fb
>      add     a3,a3,1234 # c0000000
>      li      a5,-1
>      lui     a4,0xc0000
>      addw    sp,sp,-96
>      srl     a5,a5,0x20
>      subw    a4,a4,a3
>      auipc   a2,0x111a
>      add     a2,a2,1212 # c1d1f000
>      sd      s0,80(sp)----+
>      sd      s1,72(sp)    |
>      sd      s2,64(sp)    |
>      sd      s7,24(sp)    |
>      sd      s8,16(sp)    |
>      sd      s9,8(sp)     |-> All <= 32b widths, but occupy 64b
>      sd      ra,88(sp)    |   stack space.
>      sd      s3,56(sp)    |   Affect memory footprint & cache
>      sd      s4,48(sp)    |   performance.
>      sd      s5,40(sp)    |
>      sd      s6,32(sp)    |
>      sd      s10,0(sp)----+
>      sll     a1,a4,0x20
>      subw    a2,a2,a3
>      and     a4,a4,a5
> 
> So here is a proposal to riscv 64ilp32 ABI:
>  - Let the compiler prevent callee saving ">32b variables" in
>    callee-registers. (Q: We need to measure, how the influence of
>    64b variables cross function call?)
> 
> EF_RISCV_X32
> ------------
> We add an e_flag (EF_RISCV_X32) to distinguish the 32-bit ELF, which
> occupies BIT[6] of the e_flags layout.
> 
> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>   Class:                             ELF32
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              REL (Relocatable file)
>   Machine:                           RISC-V
>   Version:                           0x1
>   Entry point address:               0x0
>   Start of program headers:          0 (bytes into file)
>   Start of section headers:          24620 (bytes into file)
>   Flags:                             0x21, RVC, X32, soft-float ABI
>                                                 ^^^
> 64-bit Optimization problem
> ---------------------------
> There is an existing problem in 64ilp32 gcc that combines two pointers
> in one register. Liao is solving that problem. Before he finishes the
> job, we could prevent it with a simple noinline attribute, fortunately.
>     struct path {
>             struct vfsmount *mnt;
>             struct dentry *dentry;
>     } __randomize_layout;
> 
>     struct nameidata {
>             struct path     path;
>             ...
>             struct path     root;
>     ...
>     } __randomize_layout;
> 
>             struct nameidata *nd
>             ...
>             nd->path = nd->root;
>     6c88                    ld      a0,24(s1)
>                                     ^^ // a0 contains two pointers
>     e088                    sd      a0,0(s1)
>             mntget(path->mnt);
>             // Need "lw a0,0(s1)" or "a0 << 32; a0 >> 32"
>     2a6150ef                jal     c01ce946 <mntget> // bug!
> 
> Acknowledge
> ===========
>  - GNU:			LiaoShihua <shihua@...as.ac.cn>
> 			Jiawe Chen<jiawei@...as.ac.cn>
>  - Qemu:		Weiwei Li <liweiwei@...as.ac.cn>
>  - Benchmark:		Junqiang Wang <wangjunqiang@...as.ac.cn> 
> 			XiaoOu Chen <chenxiaoou@...as.ac.cn>
>  - Fedora:		Wei Fu <wefu@...hat.com>
> 			Songsong Zhang <U2FsdGVkX1@...il.com>
> 
> References
> ==========
> [1] https://techpubs.jurassic.nl/manuals/0630/developer/Mpro_...
> [2] https://wiki.debian.org/Arm64ilp32Port
> [3] https://lwn.net/Articles/456731/
> [4] https://github.com/riscv/riscv-profiles/releases
> [5] https://www.cnx-software.com/2021/10/25/allwinner-d1s-f13...
> [6] https://milkv.io/duo/
> [7] https://twitter.com/tphuang/status/1631308330256801793
> [8] https://www.cnx-software.com/2022/12/02/pine64-ox64-sbc-b...
> 
> Changelog:
> V2:
>  - Add u64ilp32 support
>  - Rebase v6.5-rc1
>  - Enable 64ilp32 vgettimeofday for benchmarking
> 
> V1:
> https://lore.kernel.org/linux-riscv/20230518131013.3366406-1-guoren@kernel.org/
> 
> Guo Ren (38):
>   riscv: u64ilp32: Unify vdso32 & compat_vdso into vdso/Makefile
>   riscv: u64ilp32: Remove compat_vdso/
>   riscv: u64ilp32: Add time-related vDSO common flow for vdso32
>   riscv: u64ilp32: Introduce ILP32 vdso for UXL=64
>   riscv: u64ilp32: Adjust vDSO kernel flow for 64ilp32 abi
>   riscv: u64ilp32: Add signal support for compat
>   riscv: u64ilp32: Add ptrace interface support
>   riscv: u64ilp32: Adjust vDSO alternative for 64ilp32 abi
>   riscv: u64ilp32: Add xlen_t in user_regs_struct
>   riscv: u64ilp32: Remove the restriction of UXL=32
>   riscv: u64ilp32: Enable user space runtime switch
>   riscv: s64ilp32: Unify ULL & UL into UXL in csr
>   riscv: s64ilp32: Introduce xlen_t for 64ILP32 kernel
>   riscv: s64ilp32: Add sbi support
>   riscv: s64ilp32: Add asid support
>   riscv: s64ilp32: Introduce PTR_L and PTR_S
>   riscv: s64ilp32: Adjust TASK_SIZE for s64ilp32 kernel
>   riscv: s64ilp32: Add ebpf jit support
>   riscv: s64ilp32: Add ELF32 support
>   riscv: s64ilp32: Add ARCH_RV64ILP32 Kconfig option
>   riscv: s64ilp32: Add MMU_SV32 mode support
>   riscv: s64ilp32: Add MMU_SV39 mode support
>   riscv: s64ilp32: Enable native atomic64
>   riscv: s64ilp32: Add TImode (128 int) support
>   riscv: s64ilp32: Implement cmpxchg_double
>   riscv: s64ilp32: Disable KVM
>   riscv: s64ilp32: Correct the rv64ilp32 stackframe layout
>   riscv: s64ilp32: Temporary workaround solution to gcc problem
>   riscv: s64ilp32: Introduce ARCH_HAS_64ILP32_KERNEL for syscall
>   riscv: s64ilp32: Add u32ilp32 ptrace support
>   riscv: s64ilp32: Add u32ilp32 signal support
>   riscv: s64ilp32: Validate harts by architecture name
>   riscv: s64ilp32: Add rv64ilp32_defconfig
>   riscv: Cleanup rv32_defconfig
>   clocksource: riscv: s64ilp32: Use __riscv_xlen instead of CONFIG_32BIT
>   irqchip: riscv: s64ilp32: Use __riscv_xlen instead of CONFIG_32BIT
>   add tinylab defconfig
>   64ilp32 v.s. 64lp64
> 
>  arch/Kconfig                                  |  10 +
>  arch/riscv/Kconfig                            |  49 +++-
>  arch/riscv/Kconfig.errata                     |   2 +-
>  arch/riscv/Makefile                           |  28 ++-
>  arch/riscv/configs/32-bit.config              |   2 -
>  arch/riscv/configs/64ilp32.config             |   2 +
>  arch/riscv/configs/tinylab32ilp32_defconfig   |  88 +++++++
>  arch/riscv/configs/tinylab64ilp32_defconfig   |  89 +++++++
>  arch/riscv/configs/tinylab_defconfig          |  89 +++++++
>  arch/riscv/include/asm/asm.h                  |   5 +
>  arch/riscv/include/asm/atomic.h               |   6 +
>  arch/riscv/include/asm/cmpxchg.h              |  53 ++++
>  arch/riscv/include/asm/cpu_ops_sbi.h          |   4 +-
>  arch/riscv/include/asm/csr.h                  | 189 +++++++-------
>  arch/riscv/include/asm/elf.h                  |   7 +-
>  arch/riscv/include/asm/extable.h              |   2 +-
>  arch/riscv/include/asm/module.h               |  30 +++
>  arch/riscv/include/asm/page.h                 |  26 +-
>  arch/riscv/include/asm/pgtable-64.h           |  50 ++--
>  arch/riscv/include/asm/pgtable.h              |  26 +-
>  arch/riscv/include/asm/processor.h            |   8 +-
>  arch/riscv/include/asm/ptrace.h               |  96 ++++----
>  arch/riscv/include/asm/sbi.h                  |  24 +-
>  arch/riscv/include/asm/signal32.h             |  11 +-
>  arch/riscv/include/asm/stacktrace.h           |   6 +
>  arch/riscv/include/asm/syscall.h              |   2 +-
>  arch/riscv/include/asm/thread_info.h          |   1 +
>  arch/riscv/include/asm/timex.h                |  10 +-
>  arch/riscv/include/asm/tlbflush.h             |   2 +-
>  arch/riscv/include/asm/vdso.h                 |  34 ++-
>  arch/riscv/include/asm/vdso/gettimeofday.h    |  95 +++++++
>  arch/riscv/include/uapi/asm/elf.h             |   2 +-
>  arch/riscv/include/uapi/asm/ptrace.h          |  72 +++---
>  arch/riscv/include/uapi/asm/unistd.h          |   1 +
>  arch/riscv/kernel/Makefile                    |   5 +-
>  arch/riscv/kernel/alternative.c               |  50 +++-
>  arch/riscv/kernel/compat_signal.c             |  23 +-
>  arch/riscv/kernel/compat_vdso/.gitignore      |   2 -
>  arch/riscv/kernel/compat_vdso/compat_vdso.S   |   8 -
>  .../kernel/compat_vdso/compat_vdso.lds.S      |   3 -
>  arch/riscv/kernel/compat_vdso/flush_icache.S  |   3 -
>  arch/riscv/kernel/compat_vdso/getcpu.S        |   3 -
>  arch/riscv/kernel/compat_vdso/note.S          |   3 -
>  arch/riscv/kernel/compat_vdso/rt_sigreturn.S  |   3 -
>  arch/riscv/kernel/cpu.c                       |   9 +-
>  arch/riscv/kernel/cpu_ops_sbi.c               |   4 +-
>  arch/riscv/kernel/entry.S                     |  24 +-
>  arch/riscv/kernel/head.S                      |   8 +-
>  arch/riscv/kernel/process.c                   |  10 +-
>  arch/riscv/kernel/ptrace.c                    |   9 +-
>  arch/riscv/kernel/sbi.c                       |  24 +-
>  arch/riscv/kernel/signal.c                    |  79 ++++--
>  arch/riscv/kernel/traps.c                     |   4 +-
>  arch/riscv/kernel/vdso.c                      | 102 ++++++--
>  arch/riscv/kernel/vdso/Makefile               | 232 ++++++++++++++----
>  ..._vdso_offsets.sh => gen_vdso32_offsets.sh} |   2 +-
>  .../gen_vdso64_offsets.sh}                    |   2 +-
>  .../kernel/vdso/gen_vdso64ilp32_offsets.sh    |   5 +
>  arch/riscv/kernel/vdso/vdso.lds.S             |   2 -
>  arch/riscv/kernel/vdso/vgettimeofday.c        |  39 ++-
>  arch/riscv/kernel/vdso32.S                    |   8 +
>  arch/riscv/kernel/{vdso/vdso.S => vdso64.S}   |   8 +-
>  arch/riscv/kernel/vdso64ilp32.S               |   8 +
>  arch/riscv/kernel/vector.c                    |   2 +-
>  arch/riscv/kvm/Kconfig                        |   1 +
>  arch/riscv/lib/Makefile                       |   1 +
>  arch/riscv/lib/memset.S                       |   4 +-
>  arch/riscv/mm/context.c                       |  16 +-
>  arch/riscv/mm/fault.c                         |  13 +-
>  arch/riscv/mm/init.c                          |  24 +-
>  arch/riscv/net/Makefile                       |   6 +-
>  arch/riscv/net/bpf_jit_comp64.c               |   6 +-
>  drivers/clocksource/timer-riscv.c             |   2 +-
>  drivers/irqchip/irq-riscv-intc.c              |   9 +-
>  fs/namei.c                                    |   2 +-
>  fs/open.c                                     |  22 ++
>  fs/read_write.c                               |  17 ++
>  fs/sync.c                                     |  22 ++
>  include/linux/syscalls.h                      |  35 ++-
>  init/main.c                                   |   2 +
>  kernel/signal.c                               |  24 +-
>  mm/fadvise.c                                  |  24 ++
>  82 files changed, 1526 insertions(+), 509 deletions(-)
>  create mode 100644 arch/riscv/configs/64ilp32.config
>  create mode 100644 arch/riscv/configs/tinylab32ilp32_defconfig
>  create mode 100644 arch/riscv/configs/tinylab64ilp32_defconfig
>  create mode 100644 arch/riscv/configs/tinylab_defconfig
>  delete mode 100644 arch/riscv/kernel/compat_vdso/.gitignore
>  delete mode 100644 arch/riscv/kernel/compat_vdso/compat_vdso.S
>  delete mode 100644 arch/riscv/kernel/compat_vdso/compat_vdso.lds.S
>  delete mode 100644 arch/riscv/kernel/compat_vdso/flush_icache.S
>  delete mode 100644 arch/riscv/kernel/compat_vdso/getcpu.S
>  delete mode 100644 arch/riscv/kernel/compat_vdso/note.S
>  delete mode 100644 arch/riscv/kernel/compat_vdso/rt_sigreturn.S
>  rename arch/riscv/kernel/vdso/{gen_vdso_offsets.sh => gen_vdso32_offsets.sh} (78%)
>  rename arch/riscv/kernel/{compat_vdso/gen_compat_vdso_offsets.sh => vdso/gen_vdso64_offsets.sh} (77%)
>  create mode 100755 arch/riscv/kernel/vdso/gen_vdso64ilp32_offsets.sh
>  create mode 100644 arch/riscv/kernel/vdso32.S
>  rename arch/riscv/kernel/{vdso/vdso.S => vdso64.S} (73%)
>  create mode 100644 arch/riscv/kernel/vdso64ilp32.S
> 
> -- 
> 2.36.1
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ