22.Enabling Native Library Support for QEMU-User on RISC-V.pdf

《22.Enabling Native Library Support for QEMU-User on RISC-V.pdf》由会员分享，可在线阅读，更多相关《22.Enabling Native Library Support for QEMU-User on RISC-V.pdf（24页珍藏版）》请在三个皮匠报告上搜索。

1、LORELEI：适用于通用模拟器的本地库加速方案章子杨汪沄上海交通大学RISC-V Summit China1研究背景转译工具的需求与现状2转译工具的需求3x86_64riscv64垄断APP?转译工具的研究开发已是大势所趋！现有的转译工具4Apple Rosetta 2QEMUWindows On ArmBox64BlinkenlightsHuawei ExaGearFex-Emu统统闭源统统闭源统统闭源统统闭源各有所长各有所长各有所长各有所长5研究现状动态翻译具有更高的灵活性与用户体验，是主流选择。动态二进制翻译器，备受关注的指标主要有执行效率、兼容性。在现有的二进制翻译相关的学术研究与工

2、程实现中，大部分优化措施，都集中在优化翻译规则上。源架构指令IR目标架构指令x86_64riscv64TCGMapJIT探索新的转译流程6完完完完全模拟全模拟全模拟全模拟部分模拟部分模拟部分模拟部分模拟痴于在“翻译规则”之窠臼中上下求索将“物尽其用”思想贯彻到底我是 riscv64 的x86_64 源程序x86_64 源程序以 x86_64 翻译到 riscv64 为例现状是，有些库是无法模拟的，如 CUDA 库以及硬件驱动库。内存内存基本方案使用本机动态库加速的基本方案（以 Box64 为例）7本机优势8例：做一个矩阵乘法，如果“乘法”代码来自 Native 动态库，显然速度更快，因为充分发

3、挥了本机的向量化优势，也没有转译开销。mainlibmatrix.so 效率优势：执行相同的逻辑，本地机器码直接执行比转译快得多 兼容性优势：支持 CUDA 指令、驱动指令等利用本地动态库的可行性9libc.somain模拟 x86_64 地址空间libmatrix.solibmatrix.somatrix_mul.pltprintf.pltint 30 x4010matrix_mul(impl)printf(impl)matrix_mul.wrapper0 x4010riscv64 地址空间以 Box64 为例现有方案的问题Box64 本机库加速方案的问题10通用性差1.定制的翻译框架与动态

4、链接器传统翻译器（如 QEMU），只会完全模拟，工作流程完全与本机库无关传统动态链接器（通常指 ld-linux），工作流程完全与二进制翻译无关Box64 的开发者，于是选择了从零开始开发全新的模拟器与动态链接器11libFoo.solibBar.solibc.solibSDL.soEmulated(x86_64)Native(riscv64)工作量大2.需要手工编写 Wrapper由于 x86_64 与 riscv64 不兼容，因此需要转换层（称为 Wrapper）Box64 需要手工编写 ABI 的 Wrapper（容易出错）Box64 需要手工编写每个库每个函数的 Wrapper（代码量

5、巨大）12libFoo.solibBar.solibc.solibSDL.soEmulated(x86_64)Native(riscv64)Box64 的复杂性Box64 为大量第三方库的各函数都实现了包装器，开发工程规模极大13Box64 已经包装了 100 多个库，wrapper 文件超过 450 个，总计代码行数超过 140,000 行Wrapper 的内容：1.调用约定转换2.函数指针临时替换LORELEI：通用本地库直通方案使已有的模拟器具备调用本机动态库加速的方法14Thunk Library1.转换库（Thunk Library，简称 TL）对于一个要支持本机直通的库，需要准备两

6、个转换库，一个是 x86_64（Guest TL，GTL），另一个是 riscv（Host TL，HTL）15libc.so(org)libc.solibc_HTL.sox86_64riscv64libc.soThunk Library 的代码可自动生成，再由编译器生成二进制库。SYSCALLreadwriteHost Call01对模拟器的改装2.模拟器增加系统调用处理分支新增一个系统调用（ID 很大）模拟器处理系统调用时遇到此 ID，直接转发到本机库16libc.sox86_64riscv64libc_HTL.