On Sun, Dec 26, 2021 at 4:36 PM Jisheng Zhang <jszhang3@xxxxxxxxxxxxxxxx> wrote: > > On Wed, 22 Dec 2021 20:59:30 +0800 > Guo Ren <guoren@xxxxxxxxxx> wrote: > > > On Wed, Dec 22, 2021 at 2:10 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > > On Tue, Dec 21, 2021 at 5:35 PM <guoren@xxxxxxxxxx> wrote: > > > > > > > > From: Guo Ren <guoren@xxxxxxxxxxxxxxxxx> > > > > > > > > Currently, most 64-bit architectures (x86, parisc, powerpc, arm64, > > > > s390, mips, sparc) have supported COMPAT mode. But they all have > > > > history issues and can't use standard linux unistd.h. RISC-V would > > > > be first standard __SYSCALL_COMPAT user of include/uapi/asm-generic > > > > /unistd.h. > > > > > > > > The patchset are based on v5.16-rc6, you can compare rv64-compat32 > > > > v.s. rv32-whole in qemu with following step: > > > > > > Looks good overall, see my individual replies for minor comments I had. > > Thx for the review :) > > > > > > > > I think there is a bigger question to answer though, which is whether this is > > > actually a useful feature for rv64. In general, there are two reasons for > > > wanting compat mode: > > > > > > a) compatibility with existing binaries and distros > > > > > > b) reducing the memory footprint of user space in a memory constrained > > > environment, either deeply embedded or in a container. > > > > > > For the other architectures, a) is clearly the main driver, but equally so > > > this is not the case on riscv, which does not have any legacy 32-bit > > > code. Without that, adding compat mode would mainly introduce a > > > second ABI to a lot of environments that at the moment only need to > > > support one, and that adds complexity to the implementation and > > > the extra attack surface of the second syscall ABI when an exploit > > > may be possible only in compat mode. > > > > > > There is still some benefit in b), but it would need to be weighed > > > against the downsides above. Can you explain in more detail what > > > use cases you have in mind, and which CPU cores actually support > > > this mode? > > The most reason is about b), see our customer's product: > > https://www.cnx-software.com/2021/10/25/allwinner-d1s-f133-risc-v-processor-64mb-ddr2/ > > > > So I think all our next generation rv64 cores should support > > compat-mode. Compare to releasing rv32-full core, rv64 compat-mode is > > very cheap for our CPU design. > > > > You would get the answer when our new generation CPU is announced and it's soon. > > > > What about adding RV64 ILP32 support instead? This don't need HW side > modifications so can benefit all RV64. ILP32 is another topic in C Language Data Type Models and it couldn't replace the standard rv32 ecosystem. COMPAT is a common framework in Linux (7 arches have been supported), so let rv64 support COMPAT mode is considerable. Customers would choose ILP32 / RV32-compat by themself and that depends on which one has a better ecosystem. > > Thanks > > > Currently, only qemu supports rv64 compact mode, that is my colleague > > (LIU Zhi Wei) contributed. > -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
