Skip to content

Latest commit

 

History

History
60 lines (30 loc) · 4.03 KB

2024.4.16-qemu-user-罗君.md

File metadata and controls

60 lines (30 loc) · 4.03 KB
Raw

概览

  • RPM包工作流构建于Host环境的影响

  • 对Qemu User Mode 的二进制翻译加速理解

前言

  • 此CASE 或许能帮助理解工作流
  • 此CASE 或许能帮助理解Qemu User Mode 加速

正文

RPM包工作流构建于Host环境的影响

  • 工作流描述

    • 像正常的编译安装开源软件一样， 使用 osc 工具和 obs [关系上有点类似 git 和 github 的关系] , 只是把编译安装通过 SPEC 文件自动化了 , SPEC文件会指导如何进行编译，如何进行安装等操作，同时会产出 rpm 格式的包，可以方便用户直接安装。

  • 打包环境

    • 在Host 的 /tmp/buildroot 目录下面会有一个 rootfs 【这里不是说有一个目录名叫 "rootfs" ， 而是代指某个目录具有 rootfs 结构，也就是有 /dev /var /share 等目录的一个文件系统，而 rootfs 的真正的磁盘格式也可以是 ext2 ，也可以是ext4等 】 ， 打包的环境全部在这个 rootfs 里面 ， 和 Host 环境是隔离开来的

  • 影响

    • 打包环境是与 Host 隔离开的，不会影响到 Host 环境，大可放心使用。

对Qemu User Mode 的二进制翻译加速理解

  • Linux 用户进程所能见到的硬件 [以RISCV 为例子]

    • CPU : 非完全体CPU，通用寄存器，浮点数寄存器， 且可以通过汇编或者内联汇编的方式对其进行修改，看不到 CSR 类的寄存器。
    • 内存 : 所见之处全为内存，这里没有用 "地址空间" ， 是因为和裸机不同，Linux 用户进程所见的全是内存或者空洞的地址【没有被映射的地址】， 裸机能看到的除了地址外还有一些 IO的寄存器。

  • Linux 用户进程如何访问设备

    • 如何访问设备 ： 把参数放到对应寄存器， 执行ecall ， 让内核去帮我做对应的事情

  • 对Linux 用户进程下的二进制指令类型的思考

    • 从硬件视角来看， Linux 用户进程的执行流，在运行的过程中，应该只会对某个内存空间进行 load 类的指令， 对某个内存空间进行 store 类的指令 ， 以及对自己内部的32个通用寄存器进行运算修改，32个浮点数寄存器进行运算修改, 要进行设备操作或者其他操作的时候，也只是load 或者运算一些寄存器到另一个寄存器【从外界角度来看就是准备SYSCALL的参数】， 然后执行 ecall 指令
    • 这为二进制翻译提供了可能，因为所有机器都有load 类的指令，都有 store 类的指令，也有对寄存器进行操作的指令，同时也会有syscall 的指令，但不是所有的硬件板载资源都是一样的，如果用户空间内有某一个是访问IO的指令的话，那么很难翻译到其他板子，翻译到其他的架构上。

  • 对Qemu User 加速理解

    • 在理解了上述的基础后，不必纠结于如何从A架构把 LOAD 类的指令翻译的 B 架构，我们只需要知道这种是能实现的。Qemu User为我们提供了这个过程。
    • 现在我们需要在X86架构的机器运行 RISCV 的 Linux 用户进程，所有的RISCV的运算类指令会被成功翻译，LOAD STORE类指令也会被成功翻译，SYSCALL也会被翻译，所以本质还是运行的X86下的代码，从外界来看像是： riscv 的 ELF可执行文件 在x86 架构下被成功运行，而且是共享了一个内核的【这里区别于 qemu-system-riscv64 是模拟运行了一个Linux内核的方式，模拟器内跑了一个Linux 内核，Host 也跑了一个Linux内核】

参考