diff --git a/articles/20220627-QEMU-Support-for-the-RISC-V-Instruction-Set-Architecture.md b/articles/20220627-QEMU-Support-for-the-RISC-V-Instruction-Set-Architecture.md new file mode 100644 index 0000000000000000000000000000000000000000..8981f10f14028858d1017e3c4085544508de1ff0 --- /dev/null +++ b/articles/20220627-QEMU-Support-for-the-RISC-V-Instruction-Set-Architecture.md @@ -0,0 +1,272 @@ +# 介绍 + +> Author: ZhaoS
+> Date: 2022/06/27
+> Revisor: 1044239768@qq.com
+> Project: [QEMU 支持 RISC-V 指令集架构](QEMU-Support-for-the-RISC-V-nstruction-Set_Architecture) + +RISC-V 是一种新的指令集架构，最初旨在支持加州大学伯克利分校的计算机架构研究和教育。RISC-V 现在将在 RISC-V 基金会的治理下成为行业实施的标准开放架构。 + +本演讲将总结 RISC-V 和开放 ISA 对开源系统软件社区的好处。演讲的第一部分将关注 RISC-V 特权规范草案，包括 RISC-V 愿景，即硬件、管理程序和操作系统之间的更清晰抽象。 + +该演讲还将讨论我在 QEMU 中提出 RISC-V 仿真支持的经验，包括添加架构支持、实验设备和针对 golden reference RISC-V 模拟器 Spike 的模糊测试。演讲最后将概述在 QEMU 中为 RISC-V ISA 支持做出贡献的机会。 + +Sagar Karandikar +加州大学伯克利分校研究生研究员 + +--- + +## 视频内容 + +> 本文主要是根据 https://www.youtube.com/watch?v=b5g8u3GA-lo 的视频内容制作而成，如果有地方不准确，希望收到你反馈，我会及时修改的，谢谢。 + +Sagar Karandikar 是伯克利大学的博士，一致致力于在 QEMU 中添加对于 RISC-V 的指令支持。 + +* 主要讨论为什么 RISC-V 的开放 ISA 的好处？是希望不会太难卖。 +* 了解一些关于 RISC-V ISA 基础内容，以及为什么设计 ISA？ +* 讨论使用经典的虚拟化技术的支持，在虚拟机管理程序规范中存在的差距？ +* 讨论对 RISC-V 的 QEMU 目标支持？ +* 讨论关于正在进行的工作类型，以及对 QEMU 的上游做了什么，以及未来的规划？ + +--- + +## 1. 主要讨论为什么 RISC-V 的开放 ISA 的好处？ + +### ISA 并不是很重要 + +如果我们在看一个完整计算机系统时，有很多不同因素会影响机器上运行应用程序的性能和功耗特性。因此从一开就知道你设计的某些算法具有一定的运行时复杂性，我们必须随后担心，编写代码实现质量很重要，然后我们必须通过编译器、操作系统或其它什么语言去运行。这里的 ISA 是一个特定组件，在使用 ISA 后，还有很多重要的事情去做，当我们设计的微架构或者实际设计核心内容时，我们需要考虑那些内容的权衡，比如有缓存有多大。甚至一旦我们完成了架构工作，就知道了如何正确地制造芯片，芯片会有很多东西影响实际系统正常的运行方式。因此从这个角度来看，ISA 并不是很重要，只是巨大内容一小部分，但你可以说你的指令集很重要。 + +--- + +### 为什么指令集设置架构很重要 + +* 为什么不适用 Intel 销售移动芯片？ + * 99% 的移动手机芯片都是基于 ARM v7/v8 的 ISA。 +* 为什么 ARM 不能用于销售的服务器？ + * 99% 现有的服务器都是基于 AMD64 ISA 构建的，并且超过 95% 都是由英特尔提供的。 +* 怎么 IBM 仍然销售大型计算机？ + * 其中很多古老的机器是基于 IBM 360 系统的，其中 ISA 已经存在了 50 多年。 + +对很多问题的答案是，软件成本真的很高，可以构建在这些主机上运行良好的软件，不同机器类型需要付出很多成本，因此鉴于此，我们可以争辩说我们的 ISA 实际上是计算机系统中最重要的接口，这最终是我们从构建一个 fixed 开始，在固定硬件功能到真正可以编程的任何东西。 + +--- + +### 为什么如此多的 ISAs 在集成芯片上？ + +>如图所示，展示了 NVIDIA Tegra SoC。 + +![NVIDIA_Tegra_SoC](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/NVIDIA_Tegra_SoC.png) +如果我们更近一步喜欢现代系统，那么不仅仅是一个片上系统，这里有一个 NVIDIA Tegra SoC，有很多不同的类型板载处理器，还有加速类处理器，有图形处理器，图像处理器，各种 DSP，安全处理器，电源管理单元，有时只有常规内核。应用处理器太大了，无法更好地用于小型加速器，当我们构架片上系统时，会从各种供应商和这些 IP 中的每一个都有自己专有的权利，有时想开发自己的核心，如果您正在构建这些加速器之一，甚至构建自己的 CPU，使用自己的 ISA，因为它们需要一些受限制的功能集，或者需要添加不存在的功能，因此必须不断的推出新的编译器和操作系统，因此今天的 SoC 板载了十多个 ISA，其中每个 SoC 都必须有自己独特的软件，所以这是大量的工程工作。需要做一些已经完成的事情。 + +--- + +由此产生了几个问题，列表： + +* 我们需要这些不同的 ISAs 吗？ +* ISA 一定是专有的吗？ +* 最重要的是如果有一个免费和开放的 ISA，可以提供给你使用吗？ + +--- + +### ISAs 应该是开放和免费的 + +对于以上的问题，应该认为 ISA 自由和免费的，不受任何法律的约束，因此更多 ISA 出于各种原因是专有的，但是在很大程度上，这些原因是历史原因或者商业原因。因此，对我们现在还有没有一个开放的 ISA，这并不是一个很好的技术原因，这并不是很多人的遗漏，也不是像在这些大公司之一工作的人，有一天突然离开了，说一句：天哪，我忘记开源我们的 ISA 了。这并不是因为公司进行了大部分软件开放，正如我们看到那样，很多贡献者，甚至在很多机器上运行的系统软件，很多公司也没有专门设计经验，以及专门介绍 ISA 的教科书，来介绍 ISA 的行为有何不同，那种 ISA 功能是好的、坏的、现代的以及采用现代的实施技术等等，最受欢迎的 ISA 绝对不是最精彩的，大多数有用的 ISA 随着时间的推移与遗留的问题建立起来的复杂性，并且没有公司专门验证 ISA 兼容性的正确性，你可以轻松拥有某些类型的基础来创建兼容性，以确保每个处理器的某些流程，在人实施的时候，尽可能的规范、正确或者尽可能接近我们可以确定规范匹配。过去公司拥有自己的 ISA，可是有些公司已经消失了，并且那些 ISA 不受支持了，所以不能保证仅仅因为有一家大公司支持 ISA，这样它就会永远的持续下去。 + +--- + +### 免费和开放 ISA 的好处 + +拥有免费和开放 ISA 的好处是什么呢？更大的创新将是自由市场竞争，因为 ISA 是标准化的，并且任何人都可以实现与之匹配的内核，因此您可以拥有不同的内核，包括封闭的源代码和开放的源代码，并且您获得帮助，通过共享开放核心设计的方式，因此我说大部分系统构建的实际核心板载性能并不是产品差异化因素，所以在这种情况下，设计师真正需要更好的功能和执行指令的内核。拥有这些共享的开放式设计确实是很有用的处理器。因为越来越多的类型提供更实惠的价格设备，所以这些设备就像物联网设备一样，作为你真的想要的便宜的东西，比如说如果你能得到一些免费和开源的东西，你并不是需要最快的 CPU，这是一种很好方式，与此同时，系统的软件堆栈可以很长时间存在，当从事它们工作的人分布在一家无任何相关公司的情况下，你可以升级所需要的软件，以便能够升级系统中的软件，对于 IoT 类型的设备，例如已经嵌入具体功能的系统因此需要长期支持才能使得正常工作。最后在系统研究社区发展的一件事情，是可以做非常好的实践研究，因为哪里有所有可用的开源系统软件，所以在架构领域，我们想拥有完全开放的硬件堆栈，来使得架构研究更加真实，然后将所有软甲都预先构建在上面，这样从事研究的人可以修改真实设备中实际使用的真实内核了，假如它们是开源的，并且他们得到所有投入软件的工作。你知道移植 GCC 类型的内容以及所有相关的东西都是开放的。 + +--- + +## 2. 了解一些关于 RISC-V ISA 基础内容，以及为什么设计 ISA？ + +### RISC-V 的起源 + +在 2010 年，经过很多年使用不同国际标准，伯克利大学的计算机体系结构研究人员研究了他们希望在下一组项目中使用的 ISAs，多年来 RISC-V 有很多明显的选择，例如 x86 和 Arm。如果首先使用 x86 实现，它复杂了，所以你知道我们可能采用几个博士来实现它。假如我们使用它，并且设计的处理器可以工作，然后，我们就可能被起诉了，所以这么去做并不是很好。 + +--- + +### Intel x86 "AAA" 指令 + +你知道，这将作为复杂性的一个样本，比如，"AAA" 指令是 Intel x86 的东西，这对于使用 BCD 数学来说真的很复杂，但它是一个单字节指令，在现在机器中并不是那么重要，但是如果你想要一个 x86 兼容的处理器，你必须实现一些东西，当你尝试时，我们可以对 ARM 说同样的内容，使用 ARM 实现一种不错的简单处理器，它非常复杂，最后你要么必须支付很多钱，要么最终被起诉，这是同样的问题，所以，在伯克利大学，我们在 2010 年夏天开始一个为期 3 个月的项目，开发我们自己的 clean-slate ISA，这里列出主要的设计师：Andrew Waterman, Yunsup Lee, Dave Patterson, Krste Asanovic principal designers，他们在一家初创公司，该公司正在基于 RISC-V 构建更多处理器核。 + +--- + +### RISC-V 背景（部分） + +这里想说更多的背景，在 2014 年 5 月，有很多芯片在本次讨论，在伯克利大学真的有很多关于 RISC-V 研究内容，因此 RISC-V 来实际开发用于研究系统，同时选择 RISC-V 这个名称，使用 RISC-V 来代表伯克利大学的 RISC-V 设计历史，在 1981 年就有了最早的 RISC-V 出版物和各种修订版，并进行进一步的开发，一直坚持测试和实现，其中影响了架构，例如 RISC-I,、RISC-II、SOAR、and SPUR。因此 RISC-V 是伯克利大学的第五个版本。如果我们回到 2014 年的八月，公司的章程被提交，用于创建一个非盈利性 RISC-V 基金会来管理 ISA，并确保它发展没有像伯克利大学这样特殊的利益需求控制。 + +--- + +### RISC-V 并不是一个开源处理器 + +RISC-V 是什么？最总要的，RISC-V 并不是一个开源处理器。所以它只是一个 ISA 规范，不属于任何组织，因此在伯克利大学，我们开发了软件和开源内核处理器，实现了 RISV-V ISA，但是 ISA 是独立的，它是实物，它是开源的。因此任何人都可以实现符合 RISV-V ISA 规范的内容。例如，你不会因为 RISC-V 而被起诉。这样做的原因是以及芯片设计大部分的成本多是软件成本，因此提前在特定芯片上符合一个标准的巨大软件堆栈是一种方法，您可以在一堆不同芯片设计中重用它。基金会的目标是为了确保 ISA 良好发展，更好得到社区的反馈，我们希望鼓励 RISC-V 规范的开源和专有实现，所以这不意味则着它设计东西必须开源，这样公司可以使用它构建自己粉笔源代码核心，并在上面加上特殊的设计，这样他们就不必须开源。 + +--- + +### 伯克利大学 RISC-V 核心 + +这是伯克利大学核心简要历史： +![伯克利大学核心简要历史](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/伯克利大学核心简要历史.png) +这些都是伯克利大学设计的，伯克利也有实际芯片设计，它们上面运行 Linux 之类的系统，它们的性能相当的高，特别是提到是它们是由几个研究生制作的，我们使用非常现在的流程制造他们，这个时间表一直在继续，我们不断向工厂发送芯片，我们可以继续让他们回来使用，他们变的越来越好，所以我们有 RISC-V 的实际实现，还有和其它初创公司一起努力构建 RISC-V。 + +--- + +### 背后一些支持者 + +这些是 RISC-V 背后支持者： +![RISC-V_背后支持者_1_2016_年](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_背后支持者_1_2016_年.png) +现在有很多公司加入 RISC-V 基金会，有很多已经付钱参与 RISC-V 标准化流程的工业，成为了赞助商，以及指导内容和未来。另一张有更多公司，也做出很多贡献。 +![RISC-V_背后支持者_2_2016_年](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_背后支持者_2_2016_年.png) + +--- + +## 3. RISC-V ISA + +### RISC-V ISA 介绍 + +这里将快速讨论 ISA 本身，这里定义三个不同的寻址地址，我们知道的 32 bit 用于嵌入式类型系统的，64 bit 用于服务标准桌面类型机器，还有一个 ISA 规定的 128 bit 地址，用于未来使用和更大的数据中心。最基础的 ISA 仅仅使用不到 50 个指令集，这足以支持编译器和连接器，或者操作系统的特权指令。RISC-V 使得在顶部添加扩展变得非常容易，所以这个想法是与其他 ISA 或者以前 ISA 不同，规定预定义的特定区域，这样您就可以很容易知道，将来有一个软件可以准确地告诉处理器实现的 ISA 版本，以及所有这些功能，是因为它在一开始就被嵌入到 ISA 中，所有的功能。测试所有功能都是预先计划好，所以有更标准的扩展，为我说的通用目的提供了东西，比如浮点和原子，类型的操作。你看在 ISA 是一个水平，因此与其它类型的风险相似，事实上，伯克利大学近期一些技术报告做了一些事情，相比之下，ISAs、x86 和 ARM 都谈到了很酷的 makearov、fusion。ISA 确实是为了扩展和定制而设计的，因此人们想要在 ISA 中添加东西和标准扩展和非标准扩展的期望，因此 ISA 的设计是为了更好的适应未来的扩展，而不会破环一些虚拟化之类的事情，我们已经拥有了 12 个 64 bit 硅原型，所以它们实际上是我们拥有 RISC-V 的真正实现，使得我们可以在上面运行 Linux。 + +--- + +### RISC-V 标准基于 ISA 的信息 + +有几种指令格式是基于 32 bit 固定宽度的，自然对齐，相对简单，有 31 个寄存器，加一个 0x zero register，rd/rs1/sr2 固定位置的，并且没有任何隐藏寄存器，例如，AAA 指令使用了一组特定的寄存器集，这些寄存器并不是指令本身的一部分，所以在这里 rd 就像是指定的一样，当你看指令时，就知道它正在使用什么寄存器并且在后台没有任何魔改，另一个特性是立即数总是符号扩展，所以如果你看像 MIPS 这样的东西有有很多规则是关于什么事情得到扩展你的在这里发生的事情，很容易记住一切得到扩展。浮点数添加浮点扩展寄存器，浮点控制状态寄存器以及一些额外的指令格式，例如 fuse 乘法的添加在你指定的寄存器中，并且基础是一个旨在非常巧妙地允许与位置无关代码和动态链接之类的东西而没有奇怪的东西。 + +--- + +## 4. RISC-V 中 QEMU 都有那些，包含什么内容？ + +### RV64 是什么？ + +RV64 是 general-purpose 的 ISA，也就是现在在 QEMU 里面的，这是 QEMU 的版本实现的，G 代表是 general-purpose，包括标准扩展 I，M，A，F，D，我是基于在前几张幻灯片中讨论的一个，比如你想在常规桌面类或服务器类系统中添加扩展，基于其它标准扩展。因此你有标准整数乘法和除法扩展，然后是 32 位和 64 位浮点扩展，就像我说的，这是 ISA 的标准通用版本，这就是 QEMU 实现的特权部分，到目前为止，这里我展示是标准化的东西，用户级别是固定标准化，并且不会改变。 + +--- + +### RISC-V 特权规范 + +它仍然在开发中，所以我会讲它的现状如何，但其中有一些东西在未来可能会发生变化，所以现在有四种特权模式，User，Supervisor，Hypervisor，Machine，每个模式都是需要机器模式，常见的情况是提供机器管理模式和用户模式来允许类似 unix 操作系统之类的内容，这就是 QEMU 现在所作的事情，如果你担心内存转换的内容，所以虚拟内存架构基本上是为了支持你知道标准的类 Unix 操作系统，所以这里没有什么疯狂的事情，例如 Sv39（RV64）规范，在 RV64 中使用，而 64bit RISC-V 使用了常规的东西，所以在这种情况下你得到一个需求页面虚拟地址空间，Sv39 意味着，它是一个 39 位 虚拟地址空间 3 级页表，你可以拥有各种各样大小的页，标准为 4 KB，并且有各种不同的地址空间大小，具体取决与你的系统需求，这些都是在规范中标准化，所以这是特别有趣的内容。 + +--- + +## 5. 关于 RISC-V 虚拟化 + +### RISC-V 虚拟化 + +简单谈谈关于虚拟化，RISC-V 虚拟化是一种经典虚拟化，从一开始就融入了 ISA，我们试图关注虚拟化，关于虚拟化我们的系统很容易，所以你只是使用用户管理模式和机器模式，RISC-V 被设计为在这个意义上可以虚拟化，因此这是直接来之与手册的引述，以表明设计人员正在关注正确的特权架构，为了简化客户操作系统使用经典虚拟化技术，让其在用户级别允许，并且由于可以轻松检测和跟踪少数特权指令，因此我将简要讨论如何在原始 VMware 论文的上下文中避免一些经典的虚拟化问题，该论文描述了它们在添加虚拟化是遇到的一些困难，是一个运行在 x86 上的操作系统。 + +--- + +### 处理敏感但非特权的指令 + +处理敏感但没有特权的指令，因此如果你在为这些指令在 x86 构建 VMware 时查看这篇论文，他们会有列表列出了 x86 架构的 19 条指令，这些指令不幸违反了 Popek and Goldberg’s 的规则，因此在没有任何黑客攻击的情况下制造了 x86 非虚拟化，因此在 RISC-V 中没有这种隐藏的特权状态读取或写入，所以有一个小部分特权可以修改特权状态的空间，我们称之为“控制状态寄存器”，这是特定寄存器的地址空间，并且在寄存器编号中编码的有关权限的信息，例如，你必须处于那种模式才能读取或写入此特定寄存器，因此很容根据你的所处的模式告诉你允许修改，因此很容让你知道本机的常规允许内容，并为特权指令执行陷阱和模拟，当你在尝试虚拟化时，遇到这些内容，但是 RISC-V 基本上没有这个问题，这个隐藏的特权状态读取和写入。 + +--- + +### 追踪虚拟机内存的变化 + +对于原始的 VMware 这是引用特权硬件寄存器包含段描述符表和页表的地址，但是这些东西会被常规的加载和存储修改，这些显然不会有问题，所以你不能告诉这是怎么回事，因此在 RISC-V 中你仍然使用定期加载和存储以及修改内存的管理状态，但根据规范，需要在加载和存储只有有这个 SFENCE.VM 指令，像页表一样修改，如果你在运行它，这是一个特权指令用户模式，它会使你陷入困境，你就会知道，你可以做你通常的模拟来修复你的监控器。 + +--- + +### 虚拟化分段 + +最后时虚拟化分段，这是一种最简单的修复，所以不得不把这段写在这里，因为它太复杂了，不能放在 PPT 上，但基本上你知道各种各样的隐藏状态，当你在 RISC-V 中处理段描述符表和寄存器之类的事情时，大量隐藏状态会在 x86 中被修复，修复是很简单的，没有 x86 的分割，在分页之上的分割，所以如果你想要这种有限的基本入栈模式，这可以在机器模式和类似的内容使用，你会得到几个段，同时得到这种简单的保护，但是我们希望常规系统将使用分页代替，所以由于我们要求很低，我们没有这个问题，隐藏状态被修改为段处理和类似的内容，以及我们内存管理是通过页面发生的，并且在很容检测到。 + +--- + +### RISC-V 虚拟化堆栈 + +在 ISA 发生另一件事情是内部软件的逻辑故障，在 ISA 的设计目的是让虚拟化变得非常容易，因此在我所说的在运行软件中拥有更简洁、抽象的想法：“应该可以很容地交换任何这些基本组件并行虚拟化：，所以这个是我们想在软件堆栈本身内部提供非常干净的定义明确的层，这样您就知道一些已经常见的东西，你的应用程序通过一些应用二进制接口与 OS 通信，所以这没什么不同，但我们想在 RISC-V 中将其一直扩展到堆栈，例如，你的操作系统现在将通过一些二进制接口与由一些特权软件提供的执行环境进行通信，你就可以将其扩展到管理程序等等，所以这个想法是所有级别 ISA 都是预先设计的，用于支持虚拟化。 + +--- + +### RISC-V 管理程序规范 -WIP + +因此虚拟机管理程序规范 ions 现在是特权规范中一个空白章节，所以它是一种正在处理的东西，你可以用当前的特权设计做这个，M 模式监视器，它提供非常简单的物理资源分区并且可以充当，非常简单的虚拟机管理程序。当然我们希望在顶部有更多功能齐全的虚拟机管理程序，所以会有一个虚拟机管理程序扩展规范，就像我说的那样，如果你有兴趣参与其中，它现在是特权架构设计中的一个空位，我会鼓励你加入一个开发邮件列表，这个想法是会有有人这个初稿的，然后草稿会在开发邮件列表上进行循环，我们会接受反馈，事情会得到修复，然后它通过基金会中的不同委员会，并在让我们知道它运作良好后，最后获得批准。 + +--- + +### RISC-V 的生态 + +* Github：github.com/riscv and github.com/ucb-bar +![RISC-V_年的生态](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_年的生态.png) +关于 RISC-V 生态系统本身，我们构建了一堆软件，所以你知道你的常规编译器和内容，我们有 GCC/ glibc / GDB，可以使用 LLVM / Clang，我们有一个 Linux Port 它正在快速改进，但是启动它你可以使用它输入命令命令行，使得它为小型嵌入式系统生成嵌入式发行版，我们还有一个标准的测试的验证套件，我将快速浏览我们拥有的硬件，因此如果您想购买 FPGA 并自行设计 RISC-V 的内核，我们将拥有 FPGA 基础设施（后边会讨论这个内容），我们有 Spike，这是我们的”Golden-standard“ISA，它是一个模拟器，所以关于 Spike 的事情以及我们称之位”Golden-standard“的原因是 Spike 是由为 ISA 和 Spike 编写规范，来至同一个人编写的结果，你可以质疑它，并且说如果 spike 做了一些你被允许做的事情，这就我们一些测试的方式，我会在最后讨论这个，然后我们由 angel，JavaScript ISA 模拟器，如果你有兴趣你可以去尝试，它们可以在浏览器中启动 Linux，然后就是 QEMU 的内容，稍后回谈论这个，然后我们还有一堆硬件实现，芯片或者内核，这是一个 RV64G 单一问题的内容，我们有 Sodor 处理器，它是用于教育的处理器，然后我们也有 BOOM 这是我们一种（伯克利 Out-of-Order Machine）没有顺序各种规模的处理器，在上边已经展示很多了与各种 arm 内核的可比指标。 + +--- + +## 6. 对于 QEMU，RISC-V 支持的目标 + +### 概述 + +这里将谈谈 RISC-V 目标对 QEMU 的支持，所以现在这里在 GitHub 上的 RISC-V 组织上进行维护的，我们显然希望上游加入它们，我们想在几张 PPT 中为说清楚为上游做了什么内容，这里维护我们现在在现在 x86 上拥有 QEMU 完整的系统模拟器是没有 Linux 用户模式，非常有趣的是 QEMU 是最快的 RISC-V 实现，这里可能将在知道 1-2 年的后，因为真正的核心开始出现，但是现在我们是最快的，一件很酷的事情是，这对开发 RISC-V 软件将有很大的帮助，尤其是当我们不这样做的时候，在等级核心上真的很强大，这可以很快开发软件。这里展示它的工作原理，所以在左侧一个启动 Liunx，在右侧 QEMU 已经完成了，所以你会看到右侧完成启动，这样你就可以允许命令行了，并且使用它做任何事情了。 +![在_Linux_中启动_QEMU_中_RISC-V](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/在_Linux_中启动_QEMU_中_RISC-V.png) + +--- + +### RISC-V 的时间线及”第一次“ + +简要讨论 在 RISC-V 的时间线中很多第一次发生在 QEMU 的事情，因为我们开始了 QEMU 时，当时我还是 XXX，2014 年的，好像时 2014 年 5 月什么的，大约一个月后我就开始 QEMU，我们在 QEMU 上进行了第一次 Linux 启动，它立即成为最快的 RISC-V 实现，然后它也是第一个具有 TCP/IP 服务的网络，所以我们有 Vert IO 网络设备，你可以关联到 Linux 上通过 VNC 运行的 GUI 交互，然后它也是第一个 Python 的一部分，所以第一个真正软件 Python 是在 QEMU 上运行的 RISC-V 之上运行的。第一个运行 Java 启动也发生在 QEMU 上运行的 RISC-V，我认为特别酷的是，第一个 RISC-V 内核建立在 RISC-V 系统上在 QEMU 中。然后我们在 2016 年初做的下一件事情是 bump 特权规范，所以特权规范任然在发展，这是一个相当大的飞跃，所以我们升级一个新的特权规范，随之而来第一个 RISC-V 系统，你可以使用 debug 通过 GDB 服务器远程调试 GDB，在几周前对特权 1.9 规范进行了另一次 bump，希望我们在完成初步准备后，尽快启动流程测试。 + +--- + +### RISC-V 芯片上开发 RISC-V + +这里将简要介绍一下我们在伯克利是如何制造芯片的，所以我们有自己的 DSL 用于开发称为 Chisel 的芯片，所以这个想法它不像高级合成，它不像你编写 C 程序并将其转换成电路芯片，Chisel 是一种是开发硬件变得更容易的方法，类似与你在日志中所做的那样，你仍然在描述硬件，但是想法是你应用良好的软件工程技术和良好的编程语言特性来设计硬件，所以 Chisel 是嵌入在 Scala 中用于生成硬件的 DSL，因此为了实际知道芯片，尽管我们最终需要生成错误日志，所以我们编写所有我们的芯片和 Chisel，和所有展示这些照片，以及之前展示照片，这些都是用了 Chisel 编写的，然后我们在 JVM 上运行 Chisel 编译器以及发出错误日志，然后通过所有 CAD 工具，所以这里有个非常棒的本科是提出一个简单的 JVM 端口，经过大量工作后来解释的版本，所以这里是在 QEMU 内部运行，可能很难在后面看到，但这里是 Chisel 的源头，停留在我们教育阶段课程并在 QEMU 之上运行它，你在 RISC-V 系统上运行它会有大量日志，然后你可以执行，并通过 CAD 工具进行操作，所以虽然着很酷，但它有点像第一个自我托管的以某种方式运行 RISC-V 系统。 + +--- + +### RISC-V 目标对 QEMU 的支持 + +对于 RISC-V 支持的更多信息，我们支持了什么，我们早在 2014 年，正如我在上一张 PPT 上向你们展示的那样，随着 ISA 的发展，我们一直在修改内容，自我更新，所以我们支持我们 RV64G 完整系统仿真用户是一种支持，从那时起，它 2.0 版本中已经标准化，我说的特权已接近标准化，至少机器管理员模式和用户模式为 1.9，因此 RISC-V 版本 2.0 通常意味着，你知道的标准固定版本，不过好处是未来对 QEMU 的特权规范审计会简单很多，因为我们至少在非常关键的性能区域嵌入一些 Spike 代码到 QEMU 中，所以它更容易嵌入对未来的事情，所以在我们这样做之前，回到 1.7 的与特权，但我不得不将他提升到 1.7 规范时，花了大约一个月的时间来做调整并确保一切正常，但在几周前我做了 1.7 到 1.9 的升级，我基本上生成了带有 Spike 的巨大差异，然后动手应用它，看看这次发生了什么，只用了三天而不是一个月，所以在这里修改显然要快速很多，一旦特权领域的事情变得稳固，我们想要优化任何可优化的内容并完成。另一个重要的功能时我现在仅限于主机目标接口设备，因此主机目标接口或者 HTIF 是我们构建时遗留的内容，通过控制台有一个 HTIF 控制台设备。我们以前有很多其它设备，在我们拥有真正的特权之前，我们正在致力于平台标准化并添加软件支持，对于一堆设备，尤其像 Linux 这样的设备。但要查看 QEMU 中硬件类型，这是您将看到的内存映射（hw/riscv/riscv_board.c），它提供一个参考板设计，用与匹配 Splike 现在的功能，因此它提供一个非常简单的硬件配置有一个基于 HTIF 的控制台，用于显示引导消息和 Linux，你知道你可以让你的中断使用，还有循环软件中断、仿真，由于特权范围的需要。还有一个 RTC 和 符合特权规范的 TIMER，然后是一个重置向量，嵌入式的 RISC-V 程序集，现在有一个配置字符串，所以邮件列表上正在讨论这个匹配字符串应该是什么样子的，这是一种自定义的东西，我认为它们正朝着用标准的设备树的方向发展这个自定义匹配字符串，但基本上它被映射到内存中，你有你的 DRAM，然后你的所有设备很快就在内存比较低的区域出现。 + +![内存映射](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/内存映射.png) + +--- + +### I/O ：HTIF（old），Debug （new） + +现在出现了 HITF 和 我们新的调试系统（正在使用），就像我说的那样，HTIF 是 伯克利测试芯片的遗物，它基本上被淘汰了，它是从主机使用的 64bit 寄存器来监听主机，这些是一个很大程度上遗留的系统，所以你有一个 FPGA 板子，在使用我们使用我们制造的芯片，所有的 IO 都由 FPGA 上的东西处理，所以我们没有必须在这些测试内容上拥有大量复杂的自定义 IO 的 IP，所以 HTIF 是逐步淘汰的内容，它曾经能够提供诸如联网块设备和控制台之类的内容，除了 QEMU 现在拥有的标准，它只是对于控制台和指令测试完成，将在稍后讨论，但是我们要替换它，使用的 RISC-V 标准的调试规范，因此我们希望在获得真实芯片后更容易调试它们，这个是我正在标准化过程中的内容，它将取代 HTIF 曾经拥有的 H-24 类型调试功能，当然对于真正的硬件和真正的软件模拟器，虚拟化环境，他们将逐步淘汰 HITF 并转向标准，一旦软件支持进展，标准设备就会发生这样的事情，所有的 HTIF 代码和 Linux 在我们获得其它设备支持之前，首先将被剥离出来，但其他设备支持正在慢慢重新添加进来。 + +--- + +### 在 RISC-V QEMU 的软件堆栈 + +这里将很快谈谈，在 QEMU 中运行的软件堆栈是什么样子的，所以基本上有一些运行安全启动的主要 M-mode 和一些监控代码，在这种情况下，它被称为 BBL，它是伯克利大学设计引导加载程序，我将确切低谈论它在下下一张 PPT 中，然后是 S-Moe 超级用户模式将运行你的操作系统，这里想法是操作系统始终运行虚拟化，因此操作系统始通过 SBI 接口与其余硬件交互，如果你有这些干净整洁的界面，那么操作系统可以直接在硬件上运行，这里使用引导加载程序，并有一些监视器模式，或者让你知道管理程序和在哪里提供 SBI 的内容，然后用户模式可以在操作系统之上运行应用程序或者如果你的 M-mode 监视器支持，则可以直接在 U-mode 下运行应用程序。 + +--- + +### Boot Up + +这个东西是如何启动的，当你向 QEMU 提供一个引导加载程序的二进制文件，并且由于引导加载程序是你拥有的 Linux 的有效负载，所以引导加载程序执行执行系统机器模式管理，并将 SBI 暴露给操作系统，例如，当 Liunx 想要打印到 HTIF 控制台，它将进行 SBI 调用和 M-mode 管理代码，将作为 Liunx 执行操作，因此 Linux 不会必须解决这个问题，这里的想法是，从长远来看，你可以编写在操作系统之外运行的设备驱动程序，这样您就不必须为开发的新操作系统编写新的驱动程序，而不是操作系统通过标准化接口与外部世界交互，在这种情况下，我们的 Linux 还包括，这样我们就不必须处于设备，但我们之前必须支持它，它很快就会被会放回，所以这个东西启动的方式是系统启动到你的硬件编码，启动 ROM，它将跳转到 BBL，BBL 将执行此处列出的所有这些管理，它将初始化操作系统期望看到的主要执行环境，然后它将在种情况下运行内核 Linux。 + +--- + +### 正在执行的测试与调试 + +这里会谈谈测试和调试，当你了解它时，你通常会知道 GDB 非常困难的调试类型，但是现在它公国了 RISC-V 标准测试，正如我之前展示那样，我们可以在上面运行相当大的软件堆栈，所以在 Python 上，我们已经完成了诸如在上面运行图像处理研究的东西，所以我们在 qmu 中开发了所有这些东西，然后最终得到了一些内容，它可以在真正的硬件上运行——我们在 JVM 之上做了一些事情，就像我向你展示了用凿子构建东西一样。 + +--- + +### 使用 riscv-torture 进行模糊测试 + +所以我们已经在 Linux 上的 qmu 之上运行了相当大的软件库存堆栈，我将快速谈论模糊测试标准，所以我们有称为 RISC-V 测试框架，本质上它的作用是它会根据你提供的一些参数生成随机指令序列，所以你给它一些混合，你希望你知道一些内存指令浮点原子的一部分，无论它会生成一个序列，然后因为我们有这个黄金标准实现，它总是被认为是正确的，它本质上是我们所做的，我们是否运行我们运行我们的代码这个生成的代码在峰值和一些替代实现上，在这种情况下你有 QEMU 然后最后发生的事情是你在这种情况下只转储一些签名，只是所有寄存器状态，你比较所以如果 如果你输出的东西与尖峰所说的不匹配，你会生成然后你做某种类型的二分搜索来准确找出出错的指令，然后我将它报告给运行测试的人，我制作了脚本在我们公开的可用的 QEMU 版本之上运行 Torture，自我我在特权 1.9 更新后重新启动它以来，我们已经积累 384 小时的无故障测试，所以我打赌在这里硬编码这个数字，因为几天前我不得不提交幻灯片，但幸运的是它在过去两天没有崩溃，所以这个数字仍然是正确的，所以自从我们进行特权 1.9 更新以来，我们还没有收到任何由 Torture 报告的崩溃，所以在这方面看起来不错的。 + +--- + +### target-riscv SLoC + +最后一件事是比较代码行，我知道这是非常不公平的，但是 arm 有 45,438，MIPS 是 37,501，x86 是 30,437，而 RISC-V 只有 5,074，当然你知道这是不公平，因为我们没有要处理的所有遗留问题，但这只是表明我们有合理数量的代码，这基本上没有做任何工作来简化事情，或者你知道清理掉那些在某些地方重复，所以这可能会得到相当不错的改进。 + +--- + +## 7. 未来的工作和想要做的内容 + +这绝对是我们想要做的最后一件事我要谈论的是我们剩下要做的事情以及我们未来想要做的事情，所以在功能方面我们肯定想添加标准设备支持，所以这主要是在 Linux 端，需要在 Linux 上完成的事情有一些事情需要在 QEMU 中完成，比如标准平台级中断控制器，但当然那里还没有真正标准化，是当前特权规范中指定的版本，所以这是需要实施的东西，当然还有 upstreaming，所以我们计划在 9 月中旬开始流媒体，我提交了一个非常大的补丁，因为我被建议，只是为了表明目标支持存在，因为我们有兴趣可能会做 chuseok 并且无论如何我们都得到了一些关于该补丁的反馈，例如已经完成了一些好东西，比如使用内置 FPU 而不是我们自定义版本的软浮动 并且 Torture 测试器还有助于确保像这样的事情是正确的，这非常有用最近我碰到了 1.9 特权规范，它比以前花费了更少的时间，所以希望这对于事情的稳定性来说是令人鼓舞的还有更多的清理工作要做，主要是我认为在我们上游之前把事情放在正确的地方是明智的，然后我们 需要对 master 进行 rebase，所以它是 kupets，我们目前正在使用 QEMU 版本，我认为就像 2016 年 12 月一样，所以我们需要 rebase，然后我们还需要把事情分解成你知道的小补丁，幸运的是我让 tricor 的维护者在这里帮助我，他最近在上游，然后在未来我们也想做一些事情，比如支持其他是一个变体，所以我们的 RV32 压缩是一个，然后还添加对像 linux 用户模式。 + +## 参考链接 + +* +* diff --git a/articles/20220705-qemu-support-for-the-risv-v-instruction-set-architecture.md b/articles/20220705-qemu-support-for-the-risv-v-instruction-set-architecture.md new file mode 100644 index 0000000000000000000000000000000000000000..bbc3d1d7940b4a7749469fcd4b03828937d2aa09 --- /dev/null +++ b/articles/20220705-qemu-support-for-the-risv-v-instruction-set-architecture.md @@ -0,0 +1,649 @@ + +> Author: ZhaoS +> Date: 2022/06/27 +> Revisor: +> Project: [RISC-V Linux 内核剖析](https://gitee.com/tinylab/riscv-linux) + +# 对 risc-v 指令集架构的 qemu 支持 + +RISC-V 是一种新的指令集架构，最初旨在支持加州大学伯克利分校的计算机架构研究和教学。现在 RISC-V 正在 RISC-V 基金会的治理下成为行业实施的标准开放架构。 + +本演讲将总结 RISC-V 和开放 ISA 对开源系统软件社区带来的好处。演讲的第一部分关注 RISC-V 特权规范草案，包括 RISC-V 愿景，即硬件、管理程序和操作系统之间的更清晰抽象。 + +该演讲还将讨论 Sagar Karandikar 在 QEMU 中提出 RISC-V 仿真支持的经验，包括添加架构支持、实验设备和针对 golden reference RISC-V 模拟器 Spike 的模糊测试。演讲最后将概述在 QEMU 中为 RISC-V ISA 支持做出贡献的机会。 + +Sagar Karandikar +加州大学伯克利分校研究生研究员 + +## 视频内容简介 + +> 本文主要梳理了 [Sagar Karandikar 的演讲](https://www.youtube.com/watch?v=b5g8u3GA-lo)，该演讲主要分享了 Sagar Karandikar 在 QEMU 中提交 RISC-V 仿真支持的经验。 + +Sagar Karandikar 是伯克利大学的博士，在 2016 年的时候，在 QEMU 中添加对于 RISC-V 的指令支持。 + +> * Why RISC-V? +> * Benefits of an Open ISA +> * RISC-V ISA Basics +> * Virtualization Support +> * QEMU RISC-V Target Support +> * Work in Progress/TODOs for Upstreaming/Future Work + +* 主要讨论 RISC-V 作为开放 ISA 将带来什么？是希望不会太难卖。 +* 了解一些关于 RISC-V ISA 基础内容，以及为什么设计 ISA？ +* 讨论使用经典的虚拟化技术的支持，在虚拟机管理程序规范中存在的差距？ +* 讨论对 RISC-V 的 QEMU 目标支持？ +* 讨论关于正在进行的工作类型，以及对 QEMU 的上游做了什么，以及未来的规划？ + +## 主要讨论 RISC-V 作为开放 ISA 将带来什么？ + +### ISA 并不是很重要 + +> * Most of the performance and energy of running software on a computer is due to: +> * Algorithms +> * Application code +> * Compilers +> * OS/Runtimes +> * ISA +> * Microarchitecture (core and memory hierarchy) +> * Circuit design +> * Physical design +> * Fabrication process +> * In a system, there are also displays, radios, DC/DC converters, sensors, actuators… + +设计师们一个完整的计算机系统时，在机器上有很多不同的影响因素，会影响着运行应用程序的性能和功耗特性。因此在设计系统的初期，他们就应该知道，设计的算法是具有一定运行复杂性。随后工程师就必须担心，实现编写代码的质量是很重要的，然后必须通过编译器、操作系统或其它什么语言去运行程序。 + +ISA 只是计算机系统中一个独特的“组件”，在确定使用 ISA 后，还有很多重要的事情去做。比如说，当设计的微架构或者实际设计内核的内容时，工程师们还需要考虑很多内容的权衡，包括需要缓存以及缓存有多大。当工程师们完成了芯片整体架构设计的工作后，就知道了如何正确地制造芯片，以及芯片包含那些内容影响着实际系统的正常运行。 + +因此根据以上的角度来看，ISA 并不是很重要，ISA 只是设计一个完整计算机系统的一小部分，但是可以说使用的指令集是很重要的。 + +### 为什么指令集设置架构（ISA）很重要 + +* 为什么 Intel 不适合销售移动芯片？ + * 99% 的移动手机芯片都是基于 ARM v7/v8 的 ISA。 +* 为什么 ARM 不能用于销售的服务器？ + * 99% 现有的服务器都是基于 AMD64 ISA 构建的，并且超过 95% 都是由英特尔提供的。 +* 为何 IBM 仍然销售大型计算机？ + * 其中很多古老的机器是基于 IBM 360 系统的，其中 ISA 已经存在了 50 多年。 + +> * **ISA is the most important interface in a computer system where software meets hardware** + +对于这三个问题的答案是：因为构建软件成本真的很高，使用不同的机器类型去构建运行良好的软件时，必须付出很多的成本。鉴于此原因，可以确定的说：“ISA 实际上是计算机系统中最重要的接口”。 + +### 为什么如此多的 ISAs 在集成芯片上？ + +>如图所示，展示了 NVIDIA Tegra SoC。 + +![NVIDIA_Tegra_SoC](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/NVIDIA_Tegra_SoC.png) + +> * Applications processor (usually ARM) +> * Graphics processors +> * Image processors +> * Radio DSPs +> * Audio DSPs +> * Security processors +> * Power-management processor + +如果更喜欢现代系统，现在系统不仅仅是包含一个 SoC 的系统。如图展示一个 NVIDIA Tegra SoC，它包含了不同类型的 SoC，具有加速类处理器、图形处理器、图像处理器、各种 DSP，安全处理器、电源管理单元、还有常见 Cortex A9 的内核。 + +>* Apps processor ISA (e.g. ARM) too large for most accelerators +>* IP bought from different places, each proprietary ISA +>* Home-grown ISA cores + +由此可知，现在 SoC 包含内容很多应用处理器，无法更好地加速 SoC 的设计。当构建 SoC 系统时，发现在各种芯片 IP 供应商中，他们每一个都有自己独特的专利。 + +如果开发者们想加速构建 SoC 系统时，想开发自己的芯片内核，甚至构建属于自己的 CPU，需要使用自己的 ISA。可是提供给开发者的 ISA 包含了一些受限制的功能集，或者需要添加不存在的功能，就必须不断的推出新的编译器和操作系统。 + +>* Over a dozen ISAs on some SoCs – each with unique software stack + +因此，如今的 SoC 板载了十多个 ISA（每个 SoC 都必须有自己独特的软件堆栈），所以，必须做一些已经完成的事情，这是需要花费大量工程的工作。 + +由此产生了几个问题，列表： + +> * Do we need all these different ISAs? +> * Must they be proprietary? +> * What if there were one free and open ISA everyone could use for everything? + +* 我们需要这些不同的 ISAs 吗？ +* ISA 一定是专有的吗？ +* 最重要的内容：如果有一个免费和开放的 ISA，可以提供给你使用吗？ + +### ISAs 应该是开放和免费的 + +根据以上的问题，伯克利的研究者们希望 ISA 是自由和免费的，不受任何法律的约束。然而，更多的 ISA 出于各种原因是专有的，这些原因在很大程度上是历史或者商业造成的。 + +> * While ISAs may be proprietary for historical or business reasons, there is no good technical reason for the lack of free, open ISAs +> * It’s not an error of omission +> * Nor is it because the companies do most of the software development +> * Neither do companies exclusively have the experience needed to design a competent ISA +> * Nor are the most popular ISAs wonderful ISAs +> * Neither can only companies verify ISA compatibility +> * Finally, proprietary ISAs are not guaranteed to last + +直到现在，还没有一个开放的 ISA，并不是因为某一个的技术原因，也不是很多人的遗漏，更不像在大公司工作的人，有一天突然离开了，说一句：“天哪，我忘记开源我们的 ISA 了”。 + +正如我们看到那样，因为大公司进行了大部分软件开源，让很多贡献者开发了在很多机器上运行的系统软件，导致越来越多的公司没有专门针对 ISA 的设计经验，以及专门介绍 ISA 的教科书。教科书可以用来帮助我们了解 ISA 的内容有何不同，何种 ISA 功能是好的、坏的、现代的以及采用何种实施技术等等。 + +最受欢迎的 ISA 绝对不是最巧妙的，大多数有用的 ISA 随着时间的推移与遗留的问题，会慢慢建立复杂性，这是由于没有公司专门验证 ISA 兼容性的正确性。开发者们希望轻松拥有某些 ISA 类型，用来创建兼容性，以确保每个处理器的流程，在人们实施的时候，尽可能的规范、正确，或者尽可能接近已经确定的规范匹配。 + +伯克利的研究者们希望可以避免，不能仅仅因为有一家拥有自己的 ISA 的公司，在公司消失后，就导致其公司的 ISA 不受支持了。这样 ISA 的支持就会永远的持续下去。 + +### 免费和开放 ISA 的好处 + +> * Greater innovation via free-market competition from many core designers, closed-source and open-source + +拥有免费和开放 ISA 的好处是什么呢？更大的创新是可以拥有自由市场竞争，因为 ISA 是标准化的，并且任何人都可以实现与之匹配的内核，所以可以拥有不同的内核，包括封闭的源代码和开放的源代码，并且开发者将获得帮助，通过共享开放核心设计的方式。 + +> * Greater innovation via free-market competition from many core designers, closed-source and open-source + +因此，这将使得大部分系统构建的内核，其性能并不能成为产品差异化因素，基于这种情况下，工程师必须需要有拥有更好功能和执行指令的内核。 + +> * Processors becoming affordable for more devices, which would help expand the Internet of Things (IoTs), which could cost as little as $1 + +拥有共享开放式的处理器是非常有用的。因为越来越多的设备类型提供更实惠的价格，使得就像是“物联网"（表示设备可以共享资源，并不是真正的连接网络的设备）设备一样。比如，当你真的想要便宜的设备，且不想要性很好的处理器，你会希望能得到一些免费和开源的支持。 + +> * Software stacks survive for long time upgrade software on systems embedded in concrete 50 years ago + +处理器被用于共享开放的方式，将是一种很好方式。与此同时，系统的软件堆栈可以被保存很长的时间。当使用它们的人分布在任何公司的情况下，可以升级所需要的软件，以便能够升级系统中。对于“物联网" 类型的设备，例如，这些设备已经嵌入具体实际工程案例的系统，是需要长期支持才能使得工作正常。 + +> * Make architecture research and education more real with fully open hardware and software stacks + +最后，通过系统研究社区的发展，可以做为一件非常好的实践研究，因为社区涵盖所有可用的开源系统软件。对于硬件架构的领域，开发者们希望拥有完全开放的硬件技术栈，来使得硬件架构研究更加符合实际工程要求，并且将所有软件都预先构建在 ISA 上。从事研究的人可以修改用于实际工程真正的内核，假如它们是开源的，就会得到所有现在已经在实际工程中使用的软件技术栈。 + +## 了解一些关于 RISC-V ISA 基础内容，以及为什么设计 ISA？ + +### RISC-V 的起源 + +> * In 2010, after many years and many projects using MIPS, SPARC, and x86 as basis of research, it was time for the Computer Science team at UC Berkeley to look at what ISAs to use for their next set of projects + +由 2010 年起，经过很多年，使用了不同国际标准，伯克利大学的计算机体系结构研究人员研究了他们希望在下一个项目中使用的 ISAs，多年来”RISC-V“项目的指令集有很多明显的选择。 + +> * Obvious choices: x86 and ARM +> * x86 impossible – too complex, IP issues +> * ARM mostly impossible – complex, IP issues + +例如 x86 的 ISA 和 Arm 的 ISA。如果使用 x86 的 ISA，同时它复杂了，可能采用很多博士来实现它。如果开发者们使用 x86 的 ISA，并且设计的处理器会成功运行了，就有可能面临被起诉的问题，所以这样做并不好。 + +### Intel x86 "AAA" 指令 + +> * ASCII Adjust After Addition +> * AL register is default source and destination +> * If the low nibble is > 9 decimal, or the auxiliary carry flag AF = 1, then +> * Add 6 to the low nibble of AL and discard overflow +> * Increment high byte of AL +> * Set CF and AF +> * Else +> * CF = AF = 0 +> * A single-byte instruction + +对于 x86 的”AAA“指令，这将作为复杂性的一个样本。 + +首先，"AAA" 指令是 Intel x86 的指令，这对于使用 BCD 数学来说真的很复杂，但它是一个单字节指令，在现在机器中并不是那么重要，但是如果你想要一个 x86 兼容的处理器，你必须实现一些东西。 + +> * Obvious choices: x86 and ARM +> * x86 impossible – too complex, IP issues +> * ARM mostly impossible – complex, IP issues + +当你尝试时，开发者们可以对 ARM 说同样的内容，使用 ARM 实现一种不错的简单处理器，它非常复杂，最后你要么必须支付很多钱，要么最终被起诉，这是同样的问题。** + +> * UC Berkeley started a “3-month project” during summer of 2010 to develop their own clean-slate ISA +> * Andrew Waterman, Yunsup Lee, Dave Patterson, Krste Asanovic principal designers + +在伯克利大学，伯克利的研究者们在 2010 年夏天开始一个为期 3 个月的项目，开发他们自己的 clean-slate ISA，这里列出主要的设计师：Andrew Waterman, Yunsup Lee, Dave Patterson, Krste Asanovic principal designers，他们在一家初创公司，该公司正在基于 RISC-V 构建更多处理器核。 + +### RISC-V 背景（部分） + +在 2014 年 5 月，在伯克利大学里面有很多关于 RISC-V 研究内容，所以使用 RISC-V 来开发项目的研究系统，同时选择 RISC-V 名称，使用 RISC-V 来代表伯克利大学的 RISC-V 设计历史。 + +伯克利大学在 1981 年就有了最早的 RISC 出版物和各种修订版，并进一步的开发，一直坚持测试和实现，其中包含很多架构，例如 RISC-I,、RISC-II、SOAR、and SPUR。因此，RISC-V 是伯克利大学的第五个 ISA 架构的版本。 + +在 2014 年的八月，RISC-V 组织的章程被提交基金会，用于创建一个非盈利性 RISC-V 基金会来管理 ISA，并确保它的发展没有像伯克利大学这样，拥有特殊的利益需求，进而被控制。 + +### RISC-V 并不是一个开源处理器 + +RISC-V 是什么？这个问题很重要。RISC-V 并不是一个开源的内核处理器，它只是一个 ISA 规范，不属于任何组织。 + +因此，在伯克利大学，研究者们开发了软件和开源的内核处理器，实现了 RISV-V 的 ISA，但是 ISA 是独立的，它是实物，它是开源的。任何人都可以实现符合 RISV-V 的 ISA 规范内容。例如，你不会因为使用 RISC-V 的 ISA 而被起诉。 + +这样做的原因，主要是芯片设计大部分的成本是软件成本。解决这个问题的办法之一是提前在特定芯片上构建符合标准的软件技术栈，让他们可以在一堆不同芯片设计中重用它。 + +设立基金会的目标是为了确保 ISA 良好发展，更好得到社区的反馈，希望鼓励 RISC-V 规范的开源和专有实现，但是这不意味则着使用 RISC-V 设计的内容必须开源，这样公司可以使用它构建自己产品（内核设计等），并在上面加上特殊的设计，也不必须开源。 + +### 伯克利大学 RISC-V 核心 + +这是伯克利大学核心简要历史： + +![伯克利大学核心简要历史](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/伯克利大学核心简要历史.png) + +图片上展示的内容都是伯克利大学设计的。伯克利大学也有实际设计的芯片，在它们上面运行 Linux 之类的系统，它们的性能相当的高，特别提到，它们是由几个研究生设计的。 + +伯克利的研究者们使用非常现代的流程制造芯片，这个时间表一直在继续，不断向工厂发送芯片，他们可以继续让他们回来使用，他们变的越来越好，所以他们有 RISC-V 的实际实现，还有和其它初创公司一起努力构建 RISC-V。 + +### 背后一些支持者 + +这些是 RISC-V 背后支持者： + +![RISC-V_背后支持者_1_2016_年](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_背后支持者_1_2016_年.png) + +现在有很多公司加入 RISC-V 基金会，有很多已经付钱参与 RISC-V 标准化流程的工业，成为了赞助商，以及指导内容和未来。另一张有更多公司，也做出很多贡献。 + +![RISC-V_背后支持者_2_2016_年](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_背后支持者_2_2016_年.png) + +## RISC-V ISA + +### RISC-V ISA 介绍 + +> * RV32, RV64, RV128 variants for 32b, 64b, 128b address spaces defined + +这里将快速讨论 ISA 本身，这里定义三个不同的寻址地址，其中 32 bit 用于嵌入式类型系统的，64 bit 用于服务标准桌面类型机器，还有一个 ISA 规定的 128 bit 地址，用于未来使用更大的数据中心。 + +> * Base ISA only <50 integer instructions, but supports compiler, linker, OS, etc. +> * Extensions provide full general-purpose ISA, including IEEE-754/2008 floating-point + +最基础的 ISA 仅仅使用不到 50 个指令集，这足以支持编译器和连接器，或者操作系统的特权指令。RISC-V ISA 使得在顶部添加扩展变得非常容易，所以这个想法是与其他 ISA 或者以前 ISA 不同，规定了预定义的特定区域。 + +这样就可以很容易知道，将来有一个软件可以准确地告诉处理器实现的 ISA 版本，以及所有功能。因为它在一开始就被嵌入到 ISA 中的所有功能。测试所有功能都是预先计划好，有更标准的扩展，为了更通用目的提供了标准，比如浮点数据和原子性类型的操作。 + +> * Comparable ISA-level metrics to other RISCs +> * Designed for extension, customization + +其实，RISC-V 的 ISA 是一个水平的内容，因此与其它类型的 RISC 相似。事实上，伯克利大学近期做了一些技术报告，相比之下，RISC-V、x86 和 ARM 都谈到了很酷的 makearov、fusion。RISC-V 的 ISA 确实是为了扩展和定制而设计的，因此人们想要在 RISC-V ISA 中添加东西和标准扩展和非标准扩展的期望，因此 RISC-V ISA 的设计是为了更好的适应未来的扩展，而不会破环一些类似于虚拟化的事情。 + +> * Twelve 64-bit silicon prototype implementations completed at Berkeley so far (45nm, 28nm) + +他们已经拥有了 12 个 64 bit 硅原型，它们实际上是他们拥有 RISC-V 的真正实现，使得他们可以在上面运行 Linux。 + +### RISC-V 标准基于 ISA 的信息 + +![RISC-V_标准基于_ISA_的信息](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_标准基于_ISA_的信息.png) + +有 4 种指令格式是基于 32 bit 固定宽度的，可以自然对齐，相对简单，包含 31 个寄存器，加一个 0x zero register，rd/rs1/sr2 位置是固定的，并且没有任何隐藏的寄存器。 + +例如，AAA 指令使用了一组特定的寄存器集，这些寄存器并不是指令本身的一部分，其中一个特性是 rd 可以指定的寄存器类型一样，当你看指令时，就知道它正在使用哪种类型的寄存器，并且后台没有任何魔改。 + +**另一个特性是立即数的符号位扩展，RISC-V 中所有立即数的符号位总是位于指令的 31 位，从而使符号扩展与指令译码并行展开。例如，如果看 MIPS 指令集的规则，就会发现关于什么事情得到扩展你的在这里发生的事情，很容易记住一切得到扩展。浮点数添加浮点扩展寄存器，浮点控制状态寄存器以及一些额外的指令格式，例如 fuse 乘法的添加在你指定的寄存器中，并且基础是一个旨在非常巧妙地允许与位置无关代码和动态链接之类的东西而没有奇怪的东西。** + +## RISC-V 中 QEMU 都有那些，包含什么内容？ + +### RV64 是什么？ + +> * G = I, M, A, F, D +> * I = Base Integer ISA +> * M = Standard Integer Multiplication/Division Extension +> * A = Standard Atomics Extension +> * F = Standard Single-precision Floating-point extension +> * D = Standard Double-precision floating-pointn extension + +RV64 是 general-purpose 的 ISA，也就是现在在 QEMU 里面实现的版本，G 代表是 general-purpose，包括标准扩展 I，M，A，F，D，这是基于在前几张幻灯片中讨论的一个内容。 + +> * This is the standard, general purpose version of the ISA, what is implemented in QEMU + +比如，当设计师想在常规桌面类或服务器类系统中添加基于其它标准扩展，里面包含有标准整数乘法和除法扩展，32 位和 64 位浮点数扩展，这是 ISA 的标准通用版本，这些标准扩展就是 QEMU 实现的特权部分，到目前为止，这里展示都是标准化内容，是用户级别的固定标准化内容，并且这些标准是不会改变的。 + +### RISC-V 特权规范 + +> * Four Privilege Modes: User, Supervisor, Hypervisor, Machine + +RISC-V 特权规范仍然在开发中，所以，这里会讲它的现状如何，但其中有一些内容在未来可能会发生变化，现在有四种特权模式：User，Supervisor，Hypervisor，Machine。 + +> * Machine Mode required +> * Common: Provide M, S, U for running Unix-like OSes (QEMU does this) +> * Virtual Memory Architecture designed to support current Unix-like operating systems + +每个模式都是需要机器模式，常见的情况是提供机器管理模式和用户模式来允许类似 Unix 的操作系统运行，这就是 QEMU 正在所做的事情。如果开发者们担心内存转换的内容，那么虚拟内存架构基本上是为了支持标准的类 Unix 操作系统，所以这里的开发内容没有很困难。 + +> * Sv39 (RV64) +> * Demand-paged 39-bit virtual-address spaces +> * 3-level page table +> * 4 KiB pages, 2 MiB megapages, 1 GiB gigapages +> * Also Sv32 (RV32) and Sv48, Sv57, Sv64 (RV64) + +例如，Sv39（RV64）的规范，在 RV64 中使用时，而且 64bit RISC-V 使用了常规的规范，在这种情况下，开发者们会得到一个需求：页虚拟地址空间。Sv39 是一个 39 位 虚拟地址空间的 3 级页表，开发者们可以拥有各种各样大小的页，标准为 4 KB，并且有各种不同的地址空间大小，具体取决与开发者们的系统需求，这些都是在规范中标准化的。 + +## 关于 RISC-V 虚拟化 + +### RISC-V 虚拟化 + +> * ISA designed with virtualization in-mind from the beginning, even when only using U + S + M modes +> * “The privileged architecture is designed to simplify the use of classic virtualization techniques, where a guest OS is run at user-level, as the few privileged instructions can be easily detected and trapped.” – RISC-V Privileged Architecture v1.9 Manual + +在这里简单谈谈关于 RISC-V 的虚拟化，RISC-V 虚拟化是一种经典虚拟化方式，从一开始就融入了 ISA。伯克利的研究者们非常关注虚拟化，希望可以非常容易地虚拟化伯克利研究者们的系统。 + +开发者们只是使用用户管理模式和机器模式，RISC-V 被设计为在这个内容上进行虚拟化，因此，这是直接来引用手册的描述，以表明设计人员正在关注特权架构的内容，是为了方便开发者们可以轻松开发操作系统中经典的虚拟化技术，让其在用户级别得到特权允许。 + +由于可以轻松检测和跟踪少数特权指令，那么 Sagar Karandikar 简要讨论了“如何在原始 VMware 的上下文中避免一些经典的虚拟化问题”，该文章描述了伯克利研究者们在添加虚拟化是遇到的一些困难，是一个运行在 x86 上的操作系统。 + +### 处理敏感但非特权的指令 + +> * In x86, for the original VMware – “Table II lists the [19] instructions of the x86 architecture that unfortunately violated Popek and Goldberg’s rule and hence made the x86 non-virtualizeable” ① + +引用内容来自于： + +> ①: E. Bugnion, S. Devine, M. Rosenblum, J. Sugerman, and E. Y. Wang. 2012. Bringing Virtualization to the x86 Architecture with the Original VMware Workstation. ACM Trans. Comput. Syst. 30, 4, Article 12 (November 2012), 51 pages. + +如果开发者们在 x86 上为一些指令构建到 VMware 时查看这篇论文，就会有列表列出了 x86 架构的 19 条指令，这些指令不幸违反了 Popek and Goldberg’s 的规则，这会造成在没有任何黑客攻击的情况下，制造了 x86 非虚拟化的情况。 + +> * In RISC-V, no “hidden” privileged state reads/writes +> * Small set of privileged instructions that can modify space of privileged state (Control Status Registers, or CSRs) + +因此，在 RISC-V 中没有类似与 x86 的隐藏式特权状态读取或写入，但是，拥有一个小部分特权可以修改特权状态的空间，称之为“控制状态寄存器”，这是它自己的特定寄存器的地址空间，并且在寄存器编号本身中编码的是有关权限的信息。 + +例如，当开发者们在尝试虚拟化时遇到特殊寄存器，告知开发者们必须处于何种模式才能读取或写入此特定寄存器，就很容易会根据所处的模式去告诉开发者们允许进行修改。如果开发者们很容易知道机器常规运行内容，并为特权指令执行 Trap 和 Emulate，所以 RISC-V 基本上没有这个问题，这个隐藏的特权状态读取和写入。 + +### 追踪虚拟机内存的变化 + +> * In x86, for the original VMware – “… privileged hardware registers contain the address of segment descriptor tables and page tables ... but regular load and store instructions can access these structures in memory.” ② + +引用内容来自于： + +> ②: E. Bugnion, S. Devine, M. Rosenblum, J. Sugerman, and E. Y. Wang. 2012. Bringing Virtualization to the x86 Architecture with the Original VMware Workstation. ACM Trans. Comput. Syst. 30, 4, Article 12 (November 2012), 51 pages. + +对于原始的 VMware 追踪虚拟机内存的变化，这是引用特权硬件寄存器包含段描述符表和页表的地址。这些内容会被常规的加载和存储修改，这显然不会 Trap，所以开发者们不会知道这是怎么回事。 + +> * In RISC-V, still use regular loads/stores to modify memory management state +> * Privileged SFENCE.VM instruction required by spec. after modifying memory management state + +因此，在 RISC-V 中，开发者们仍然使用定期加载和存储用于修改内存管理状态，可是依据规范，在加载和存储之后有 SFENCE.VM 指令，像修改页表一样。如果你在运行它，这是一个特权指令用户模式，它会使你开启 Trap，这时开发者就会知道，可以做来 Emulate 修复你的监控器。 + +### 虚拟化分段 + +> * In x86, for the original VMware – Complicated interactions between segment descriptor tables and segment registers, with visible and hidden fields. Hidden pieces updated by instructions or faults. Causes problems with extra faults introduced by a VMM.③ + +引用内容来自于： + +> ③: E. Bugnion, S. Devine, M. Rosenblum, J. Sugerman, and E. Y. Wang. 2012. Bringing Virtualization to the x86 Architecture with the Original VMware Workstation. ACM Trans. Comput. Syst. 30, 4, Article 12 (November 2012), 51 pages. + +最后，这是虚拟化分段，是一种最简单的修复。把这段写在这里，因为它太复杂了，不能放在 PPT 上，里面的内容基本上开发者们需要知道各种各样的 Hidden 状态。 + +> * In RISC-V, no x86-style segmentation +> * Limited base-and-bounds mode with 2 “segments” +> * Most software will use paging instead + +当开发者们在 RISC-V 中处理段描述符表和寄存器的内容时，大量 Hidden 状态会在 x86 中被修改，修该是很简单的，没有使用 x86 风格的分割，在分页之上进行分割。 + +如果你想要使用 paging instead，通过机器模式或者类似的模式使用，开发者会得到几个段，同时，得到这种简洁的保护，但是伯克利的研究者希望常规系统将使用分页代替。因此，他们要求很低，没有这个问题，Hidden 状态被修改为段处理或者类似的内容，以及他们内存管理是通过页发生的，并且很容易检测。 + +### RISC-V 虚拟化堆栈 + +![RISC-V_虚拟化堆栈.png](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_虚拟化堆栈.png) + +> * Provide clean split between layers of the software stack + +在 RISC-V ISA 发生另一件事情是内部软件的逻辑故障，RISC-V ISA 的设计目的是让虚拟化变得非常容易。 + +因此，Sagar Karandikar 所说的内容是在运行软件中拥有更简洁和更抽象的想法：“应该可以很容易地交换任何基本组件，并进行虚拟化“，所以，伯克利的研究者想在软件技术栈内部提供非常干净的定义与明确的接口层。 + +> * Application communicates with Application Execution Environment (AEE) via Application Binary Interface (ABI) +> * OS communicates via Supervisor Execution Environment (SEE) via System Binary Interface (SBI) + +按照上面的设计思路，开发者们的应用程序通过使用 ABI 实现与 OS 通信，这里与其他 ISAs 没什么不同。 + +> * Hypervisor communicates via Hypervisor Binary Interface (HBI) to Hypervisor Execution Environment (HEE) +> * All levels of the ISA designed to support virtualization + +伯克利的研究者想在 RISC-V ISA 中，将其一直扩展到堆栈。比如，开发者们的操作系统现在可以通过 HBI 与由特权软件提供的 HEE 进行通信，开发者们可以将其扩展到 Hypervisor 等等，所以此设计思路是为了用于支持虚拟化，所有 levels 的 ISA 都是预先设计的。 + +### RISC-V Hypervisor 规范-WIP + +> 注：关于发展内容，它是截止到 2016 年前。 +> +> * Current privileged design can have an M-mode monitor that provides physical resource partitioning, can act as simple hypervisor +> * Upcoming Hypervisor Extension Specification for “full” Hypervisors +> * Right now, an empty slot in the privileged specification + +至 2016 年以前，Hypervisor 规范是一个空白的特权规范的章节，所以，它是一种正在处理的工作，开发者可以用当前的特权模式（M 模式监视器）。它提供非常简单的物理资源分区，并且可以充当非常简单的虚拟机 Hypervisor。 + +> * Want to get involved? +> * Hypervisor Specification Draft will make the rounds soon on isadev@groups.riscv.org mailing list + +伯克利的研究者希望在顶部有更多功能齐全的虚拟机 Hypervisor。为此，会设计一个虚拟机 Hypervisor 扩展规范，现在，在特权架构设计中，它是一片空白的内容。就像 Sagar Karandikar 所描述的那样，如果开发者们有兴趣参与其中，他会鼓励开发者们加入一个开发邮件列表 isadev@groups.riscv.org。此想法有人写出初稿，在草稿会上，通过在开发邮件列表进行讨论，伯克利的研究者或者 RISC-V 组织的人会接受反馈，里面的内容会得到修复，然后它通过 RISC-V 基金会中的不同委员会讨论和测试，以便让大家知道它运作良好后，最后获得批准。 + +### RISC-V 的生态 + +* Github：github.com/riscv and github.com/ucb-bar + +关于 RISC-V 生态系统，伯克利的研究者构建了很多软件技术栈。 + +> * Software Tools +> * GCC/glibc/GDB +> * LLVM/Clang +> * Linux +> * Yocto +> * Verification Suite + +例如，常规编译器，包含了 GCC/ glibc / GDB，LLVM / Clang。在 RISC-V 中有一个 Linux Port 正在快速推进，启动它必须通过命令行输入命令运行。伯克利的研究者通过 [Yocto](https://www.yoctoproject.org/) 工具，创建用于小型嵌入式系统的嵌入式发行版 Linux 系统。 + +> * Hardware Tools +> * Zynq FPGA Infrastructure +> * Chisel + +伯克利的研究者使用一套标准的测试的验证套件，Sagar Karandikar 快速浏览使用的硬件（Zynq FPGA Infrastructure 和 Chisel）。因此，如果开发者想购买 FPGA 并自行设计 RISC-V 的内核，伯克利的研究者将提供 FPGA 基础内容（后边会讨论这个内容）。 + +> * Software Implementations +> * Spike, “Golden-standard” ISA Simulator +> * ANGEL, JavaScript ISA Simulator +> * QEMU + +RISC-V 拥有 Spike，使用的是”Golden-standard“ISA 模拟器，Spike 是一个模拟器。关于 Spike 的内容，伯克利的研究者称之为”Golden-standard“的原因，是因为 spike 是由为 ISA 编写规范的同一个人设计的，因此，开发者们可以质疑它。 + +RISC-V 有 ANGEL，JavaScript ISA 模拟器。如果开发者们有兴趣可以去尝试使用，它们可以在浏览器中启动 Linux，关于 QEMU 的内容稍后回谈论。 + +> * Hardware Implementations +> * Rocket Chip Generator +> * RV64G single-issue in-order pipeline +> * Sodor Processor Collection +> * BOOM (Berkeley Out-of-Order Machine) + +伯克利的研究者还有很多硬件实现，有芯片或者内核（有 RV64G，Sodor 处理器（用于教育的处理器），BOOM 是一种（Berkeley Out-of-Order Machine）大规模无序处理器，已经实现了很多了与各种 arm 内核可比的指标。 + +## 对于 QEMU：RISC-V 支持的目标 + +### 概述 + +> * Maintained at +> * QEMU full-system emulation + +关于 RISC-V 对 QEMU 的支持，现在在 GitHub 上的 RISC-V 组织上进行维护的，伯克利的研究者希望上游加入 RISC-V。Sagar Karandikar 用接下来几张的 PPT 中，表述清楚为上游社区做了什么工作。 + +> * QEMU on modern x86 is currently the fastest RISC-V implementation + +克利的研究者现在维护内容是，在现代的 x86 上有 QEMU 完整的系统模拟器，没有 Linux 用户模式，非常有趣的是 QEMU 是 RISC-V 最快的实现（可能在 1-2 年后，有真正的核心开始出现前），可是，现在是最快的。 + +> * A big help in RISC-V software development + +一件很酷的事情，这将是对开发 RISC-V 软件提供很大的帮助。例如，当开发者们不这样做的时候，需要在强大的核心上，可以快地开发软件。 + +![在_Linux_中启动_QEMU_中_RISC-V](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/在_Linux_中启动_QEMU_中_RISC-V.png) + +这里展示它的工作原理，所以在左侧一个 Spike 启动 Liunx，在右侧 QEMU 已经完成了，所以开发者们会看到右侧 Spike 完成启动，这样就可以允许命令行了，并且使用它做任何事情了。 + +### RISC-V 的时间线及”第一次“ + +![RISC-V_的时间线及第一次.png](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_的时间线及第一次.png) + +这里简要讨论在 RISC-V 的时间线中第一次发生在 QEMU 的事情。 + +因为伯克利的研究者开始 QEMU 项目时，是在 2014 年（似乎是 2014 年 5 月）。大约一个月后 Sagar Karandikar 参与了 QEMU 项目，在 QEMU 上进行了第一次 Linux 启动，它立即成为 RISC-V 最快的实现。 + +它也是第一个具有 TCP/IP 网络服务的，有 Vert IO 网络设备，通与在 Linux 之上通过 VNC 运行的 GUI 交互。 + +它也是第一个 Python 的一部分，所以，第一个真正软件 Python 的运行是基于 QEMU 的 RISC-V 上运行的。 + +第一个运行 Java 启动也发生在 QEMU 上运行的 RISC-V。 + +Sagar Karandikar 认为特别酷的内容，是第一个 RISC-V 内核建立在 RISC-V 系统上在 QEMU 中。 + +伯克利的研究者在 2016 年初做的下一件事情是 bump 特权规范，虽然特权规范还在发展，但是，这是一个相当大的飞跃。伯克利的研究者在升级一个新的特权规范，随之而来第一个 RISC-V 系统，开发者们可以使用 debug 通过 GDB 服务器远程调试，在几周前对特权 1.9 规范进行了 bump 特权规范加入，伯克利的研究者希望在完成初步准备后，尽快启动流程测试。 + +### RISC-V 芯片上开发 RISC-V + +这里将简要介绍一下研究者们在伯克利是如何制造芯片的。伯克利的研究者们有属于自己的 DSL，用于开发，称为 Chisel 的芯片。 + +Chisel 不像开发者们编写 C 程序并将其转换成电路芯片。Chisel 是一种使开发硬件变得更容易的方法，类似与开发者们在 Barrellogs（未知是何内容）中所做的那样，仍然在描述硬件。Chisel 的设计想法是开发者们应用良好的软件工程技术和良好的编程语言特性来设计硬件，所以 Chisel 是嵌入在 [Scala](https://www.scala-lang.org/) 中用于生成硬件的 DSL。 + +因此，为了实际制造芯片，尽管开发者们最终需要生成非常多的日志，所以伯克利的研究者们编写所有的芯片和 Chisel 的 Chisel。 + +![CHISEL_芯片.png](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/CHISEL_芯片.png) + +这里展示的照片，以及之前展示照片，都是用了 Chisel 编写的，伯克利的研究者在 JVM 上运行 Chisel 编译器以及打印了非常多的日志，然后，通过 CAD 工具实现。 + +![CHISEL_芯片启动日志.png](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/CHISEL_芯片启动日志.png) + +这里，有个非常棒的本科生经过大量工作后，实现了一个简易的 JVM 端口解释器。所以，这里是在 QEMU 内部运行，可能很难在后面看到，但这里是 Chisel 的起源，将停留在伯克利大学教育阶段课程，并在 QEMU 之上运行它。 + +开发者们在 RISC-V 系统上运行它会有大量日志，它可以执行，并通过 CAD 工具进行操作，虽然这很酷，但是它有点像第一个以某种方式运行自我托管的 RISC-V 系统。 + +### RISC-V 目标对 QEMU 的支持 + +> * RISC-V support started in 2014, evolves as the ISA does +> * Supports RV64IMAFD (“RV64G”) Full-system emulation +> * User ISA support largely unchanged since then (currently v2.0) +> * Privileged ISA nearing standardization (currently v1.9) +> * Future Priv. Spec upgrades to QEMU much simpler due to structural similarity of priv. mode emulation code with Spike +> * Pre-1.7 -> 1.7 bump, ~1 month +> * 1.7 -> 1.9 bump, 3 days + +关于更多 RISC-V 支持内容的信息，伯克利的研究者们支持了什么。在 2014 年就开始支持 QEMU 了，正如 Sagar Karandikar 在上一张 PPT 上向开发者们展示的那样，随着 ISA 的发展，他们一直在修改内容，进行自我更新，他们的推进的工作是，让 RV64G 拥有完整系统用户模拟器。从那时起，它在 2.0 版本中已经被标准化（Sagar Karandikar 说的特权已接近标准化，至少 M 模式和 U 模式为 1.9），因此，RISC-V 版本 2.0 意味着标准固定版本。 + +这样做的好处，是未来对 QEMU 的特权规范升级会简得多。因为，他们至少在非常关键的性能区域嵌入一些 Spike 代码到 QEMU 中，所以，它更容易嵌入对未来的事情。在他们这样做之前，回到 1.7 的特权开发时，花了大约一个月的时间来将版本提升到 1.7 规范，但是，在几周前 Sagar Karandikar 做了 1.7 到 1.9 的升级。 + +目标是生成了带有 Spike 版本，然后动手去实现它，这次发生了什么，只用了三天而不是一个月，所以，在这里修改显然要快速很多。至此，特权领域的规范变得稳固，开发者们想要优化任何可优化的功能内容时，会快速的很多。 + +> * I/O currently limited to “Host-Target Interface” (HTIF) devices +> * Enough to boot Linux, interact through console +> * Other devices previously shoehorned in (networking, displays, consoles) +> * Mainly waiting on platform standardization and software support + +另一个重要的功能，对现在仅限于“Host-Target Interface” （HTIF）设备是伯克利的研究者们构建时遗留内容，通过控制台有一个 HTIF 控制台设备。他们以前有构建过很多其它设备，在拥有真正的特权之前，他们正在致力于平台标准化，并添加软件支持，对于其它的设备，尤其是 Linux 使用的设备。 + +> * Reference “board” designed to match Spike + +如果要查看 QEMU 中硬件类型，通过内存映射文件（hw/riscv/riscv_board.c）可以查看，它提供一个参考设计的版本，用于匹配当前的 Splike。 + +> * Provides simple hardware, config: +> * HTIF-based console (simple, nonstandard console device for early boot) +> * “Loopback” Software Interrupt Emulation +> * RTC/Timers compliant with RISC-V v1.9 privileged specification +> * Reset Vector (Boot ROM) +> * Configuration String + +它提供一个非常简单的硬件配置，有一个基于 HTIF 的控制台，用于显示引导消息和 Linux。让你的 terminal 获得中断使用，还有循环软件中断仿真。作为特权范围的需要，包含一个 RTC 和 符合特权规范的 timers，然后是一个重置向量表，嵌入到 RISC-V 程序集。 + +现在有一个 Configuration String，所以邮件列表上正在讨论这个 Configuration String 应该是什么样子的，这是一种自定义的东西，Sagar Karandikar 认为它们正朝着拥有标准的设备树的方向发展，这个自定义 Configuration String，基本上它会被映射到 ROM 中，或者嵌入到 DRAM 中，导致所有构建的设备很快就出现在 ROM 比较低的地址空间。 + +![内存映射](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/内存映射.png) + +### I/O ：HTIF（old），Debug （new） + +> * Host-Target Interface (HTIF) is a relic of Berkeley Test Chips +> * Two 64-bit registers, fromhost and tohost + +现在出现了 HITF 和 新的调试系统（正在使用），就像 Sagar Karandikar 说的那样，HTIF 是伯克利的研究者们测试芯片的遗物内容，它基本上被淘汰了，它是从主机使用的 64 bit 寄存器，来监听主机，这是一个很大程度上遗留的系统。 + +> * Formerly provided network, block device, console, now used only for console, signaling test completion +> * Debugging: HTIF being phased out on real hardware, replaced with draft Debug Unit specification (will be standardized) +> * I/O: Real hardware/software simulators will also phase out HTIF and move to standard devices as software support progresses + +开发者有一个 FPGA 板子，将伯克利研究者们制造的芯片移植到板子上，所有的 IO 都由 FPGA 上的处理，所以，伯克利研究者没有非要在这些内容上，去测试拥有大量复杂的自定义 IO 的 IP。 + +HTIF 是逐步淘汰的内容，它曾经能够提供诸如联网块设备和控制台的功能，除了 QEMU 现在拥有 Verdi 标准，它只是用于完成控制台和指令测试。将在稍后讨论这块内容，但是伯克利研究者们要替换它的是 RISC-V 标准的调试规范。 + +因此，伯克利研究者们希望在获得实际的芯片后，更容易调试它们，这个是 Sagar Karandikar 正在标准化过程中的工作，它将取代 HTIF 曾经拥有的 H-24 类型调试功能，当然对于真正的硬件和真正的软件模拟器、以及虚拟化环境，它们将逐步淘汰 HITF 并转向标准，一旦软件的进展获得足够的支持，标准设备就会发生这样的事情。 + +在获得其它设备支持之前，所有的 HTIF 代码和 Linux，首先将被剥离出来，但是，它设备支持正在慢慢重新添加进来。 + +### 在 RISC-V QEMU 的软件堆栈 + +这里将很快讨论，在 QEMU 中运行的 RISC-V 的软件技术栈是什么内容。 + +![RISC-V_工作模式.png](images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_工作模式.png) + +> * M-mode runs secure boot and monitor (currently bbl) + +有运行安全启动的 M-mode 和监控代码，在这种情况下，它被称为 BBL。它是伯克利大学的研究者们设计引导加载程序，将确切低谈论它在下一张 PPT 中。 + +> * S-mode runs OS (OS always runs virtualized) + +S-mode 将使用超级用户模式运行操作系统，这里想法是操作系统始终运行虚拟化，因此操作系统始通过 SBI 接口与其余硬件交互。 + +> * U-mode runs application on top of OS or M-mode + +如果开发者们使用如此简单的架构，那么操作系统可以直接在硬件上运行，使用引导加载程序，包括 M-mode monitor，或者包含 hypervisors 和包含提供 SBI 的内容，使得 U-mode 可以在操作系统上运行应用程序。或者开发者的 M-mode 支持，则可以直接在 U-mode 下运行应用程序。 + +### Boot Up + +以上内容是如何启动的。 + +> * Binary supplied to QEMU contains: +> * bbl – “Berkeley BootLoader” performs Machine-Mode management of the system, exposes SBI to OSes +> * vmlinux – Linux kernel as payload for bbl +> * Includes a ramdisk for rootfs (currently limited device support) + +向 QEMU 提供一个 BootLoader 的二进制文件，这个 BootLoader 是“Berkeley BootLoader”，并且拥有的 Linux 内核信息。BootLoader 执行执行系统 Machine-Mode 管理功能，并将 SBI 提供给操作系统。例如，当 Liunx 想要打印到 HTIF 控制台，它将调用 SBI 的和 M-mode 管理代码，然后为 Liunx 执行相应的操作，让 Linux 系统不会遇到很多问题。 + +这里的看法是，从长远来看，开发者们可以编写在操作系统之外运行的设备驱动程序，这样就不必须为开发每个新的操作系统，去编写新的驱动程序，不使用操作系统通过标准化接口与外部设备交互。在这种情况下，Linux 系统需要包括 rootfs，因此不得不处理设备的内容，之前必须支持它，它很快就会被会释放。 + +> System boots into hardcoded boot rom, jumps to bbl, bbl initializes the system in M-mode, sets up Supervisor Execution Environment (SEE), then loads and runs supplied kernel, e.g. Linux + +所以，这块的 Boot Up（启动）的方式是系统引导到硬编码的引导 rom，跳转到 bbl，bbl 在 M-mode 下执行此处列出的所有内容，设置主管执行环境 (SEE)，然后加载并运行提供的内核，将在种情况下运行内核 Linux。 + +### 运行测试与调试 + +> * The usual GDB, brute force, etc +> * Passes the riscv-tests standard test suite +> * Boots Linux +> * With reasonably large software stacks on top – Python, Java, etc. +> * Fuzz testing against the “Golden Standard” + +这里讨论测试和调试的内容。开发者们一般都知道 GDB 是难度很高的调试类型，但是，现在它通过了 RISC-V 标准测试的 suite。 + +正如 Sagar Karandikar 展示的那样，在 QEMU 上运行 RISC-V 能实现在上面运行相当大的软件，通过 Python 的使用，伯克利的研究者们已经完成了运行图像处理研究的工作。 + +伯克利的研究者们在 QEMU 中开发了所有的功能，是为了进行真正的硬件开发而实现的。例如，他们基于 JVM 做了一些工作，通过使用 Chisel 构建芯片一样。 + +### 使用 riscv-torture 进行模糊测试 + +> * Generates a random sequence of instructions based on supplied parameters (% of mem instructions, floating point instructions, integer instructions, etc.) + +伯克利的研究者们已经在 Linux 上的 QEMU 之上运行了很多的软件类型。Sagar Karandikar 将快速谈论模糊测试标准，这个称为 RISC-V 测试框架，它实际的作用，它会根据你提供的参数生成随机**指令**序列，给它一些混合指令，比如，包括一些内存指令和浮点指令的一部分，它都会生成一个相应的序列。 + +> * Runs code on Spike and other implementation of your choice +> * Spike is the “Golden Reference” RISC-V Simulator, written by the authors of the RISCV Specs +> * Dump register state at the end and compare +> * On failure, binary search to pinpoint instruction where things go wrong + +基于“Golden Reference”实现，测试框架总是被认为是正确的，它实际所做的内容是匹配 Spike 运行代码。在方式下，通过 QEMU 只转储签名，只是所有寄存器状态。通过比较开发者们输出的内容与 Spike 里面内容是否匹配，会生成根据需要的类型，进行二分搜索来准确找出出错的指令，随后将它报告给运行测试的人。 + +> * Scripts for running riscv-torture on QEMU available at +> * Accumulated 384 hours of failure-free testing since August Priv. 1.9 update! + +Sagar Karandikar 制作了脚本，用于 QEMU 版本上运行 Torture，从他更新特权 1.9 后，并重新启动它以来，已经积累 384 小时的无故障测试。因为，几天前，他不得不提交幻灯片，但幸运的是它在过去两天没有崩溃，所以这个数字仍然是正确的。更新特权 1.9 以来，还没有收到任何关于 Torture 报告的崩溃，所以在这方面看起来不错的。 + +### target-riscv SLoC + +> * ARM - 45,438 +> * MIPS - 37,501 +> * x86 - 30,437 +> * RISC-V - 5,074 + +最后一件事是比较代码行，Sagar Karandikar 知道这是非常不公平的，但是 arm 有 45,438，MIPS 是 37,501，x86 是 30,437，而 RISC-V 只有 5,074。 + +当然所有人都知道这是不公平，因为他们没有要处理的所有遗留内容，但这只是表明拥有合理数量的代码，这基本上没有做任何工作来简化事情，或者清理掉重复的代码，所以这可能会得到相当不错的改进。 + +## 未来的工作和想要做的内容 + +> * Functionality: Standard device support (combo of QEMU + Linux) +> * Upstreaming! – planning to start in mid-September +> * Submitted a giant patch in February as proof-of-existence for gauging interest in GSoC +> * Some cleanup based on giant-patch feedback done (e.g. use built-in FPU) +> * Latest RISC-V Privileged Spec. v1.9 bump done +> * TODO: +> * More cleanup based on giant-patch feedback, checkpatch +> * Rebase to master (currently v2.5.0) +> * Small, logical patches +> * Future: +> * Support other ISA variants, like RV32, Compressed ISA, QEMU Linux-User Mode + +## 参考链接 + +* +* diff --git a/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/.keep b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/.keep new file mode 100644 index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 diff --git a/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/NVIDIA_Tegra_SoC.png b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/NVIDIA_Tegra_SoC.png new file mode 100644 index 0000000000000000000000000000000000000000..016cf90812376eb6272edee8167d5b5c64749774 Binary files /dev/null and b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/NVIDIA_Tegra_SoC.png differ diff --git "a/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_\345\271\264\347\232\204\347\224\237\346\200\201.png" "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_\345\271\264\347\232\204\347\224\237\346\200\201.png" new file mode 100644 index 0000000000000000000000000000000000000000..c7d0a6e10e6e163bea2274c35a695e072d23fa05 Binary files /dev/null and "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_\345\271\264\347\232\204\347\224\237\346\200\201.png" differ diff --git "a/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_1_2016_\345\271\264.png" "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_1_2016_\345\271\264.png" new file mode 100644 index 0000000000000000000000000000000000000000..97e9ac4ae711cbc50eacfb1140dd1137d852f42a Binary files /dev/null and "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_1_2016_\345\271\264.png" differ diff --git "a/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_2_2016_\345\271\264.png" "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_2_2016_\345\271\264.png" new file mode 100644 index 0000000000000000000000000000000000000000..9571bf8dea806e3542167669fc29dd06fe21ec18 Binary files /dev/null and "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_2_2016_\345\271\264.png" differ diff --git "a/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/\344\274\257\345\205\213\345\210\251\345\244\247\345\255\246\346\240\270\345\277\203\347\256\200\350\246\201\345\216\206\345\217\262.png" "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/\344\274\257\345\205\213\345\210\251\345\244\247\345\255\246\346\240\270\345\277\203\347\256\200\350\246\201\345\216\206\345\217\262.png" new file mode 100644 index 0000000000000000000000000000000000000000..4fc0265d38e1a0f3b3b6f848ac351b506f458023 Binary files /dev/null and "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/\344\274\257\345\205\213\345\210\251\345\244\247\345\255\246\346\240\270\345\277\203\347\256\200\350\246\201\345\216\206\345\217\262.png" differ diff --git "a/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/\345\206\205\345\255\230\346\230\240\345\260\204.png" "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/\345\206\205\345\255\230\346\230\240\345\260\204.png" new file mode 100644 index 0000000000000000000000000000000000000000..b728d0d9df78ddd638d8c13985146324cfd40c80 Binary files /dev/null and "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/\345\206\205\345\255\230\346\230\240\345\260\204.png" differ diff --git "a/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/\345\234\250_Linux_\344\270\255\345\220\257\345\212\250_QEMU_\344\270\255_RISC-V.png" "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/\345\234\250_Linux_\344\270\255\345\220\257\345\212\250_QEMU_\344\270\255_RISC-V.png" new file mode 100644 index 0000000000000000000000000000000000000000..c62daa81f43c84fe872fd5356621ef6c75237860 Binary files /dev/null and "b/articles/images/QEMU_Support_for_the_RISC-V_Instruction_Set_Architecture/\345\234\250_Linux_\344\270\255\345\220\257\345\212\250_QEMU_\344\270\255_RISC-V.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/CHISEL_\350\212\257\347\211\207.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/CHISEL_\350\212\257\347\211\207.png" new file mode 100644 index 0000000000000000000000000000000000000000..6c27d0ce226114d52de8cf5a241dbd46b309df7d Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/CHISEL_\350\212\257\347\211\207.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/CHISEL_\350\212\257\347\211\207\345\220\257\345\212\250\346\227\245\345\277\227.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/CHISEL_\350\212\257\347\211\207\345\220\257\345\212\250\346\227\245\345\277\227.png" new file mode 100644 index 0000000000000000000000000000000000000000..78ae603a302dbdad3ed8827e2b00c1bb2c2a13c7 Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/CHISEL_\350\212\257\347\211\207\345\220\257\345\212\250\346\227\245\345\277\227.png" differ diff --git a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/NVIDIA_Tegra_SoC.png b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/NVIDIA_Tegra_SoC.png new file mode 100644 index 0000000000000000000000000000000000000000..016cf90812376eb6272edee8167d5b5c64749774 Binary files /dev/null and b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/NVIDIA_Tegra_SoC.png differ diff --git a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/Pasted image 20220702221131.png b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/Pasted image 20220702221131.png new file mode 100644 index 0000000000000000000000000000000000000000..32bf8fba7019f212a1843d5b270774fd9e70789b Binary files /dev/null and b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/Pasted image 20220702221131.png differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\345\267\245\344\275\234\346\250\241\345\274\217.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\345\267\245\344\275\234\346\250\241\345\274\217.png" new file mode 100644 index 0000000000000000000000000000000000000000..e26688a815e8b3901656f0f9ae681af689a6b763 Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\345\267\245\344\275\234\346\250\241\345\274\217.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\345\271\264\347\232\204\347\224\237\346\200\201.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\345\271\264\347\232\204\347\224\237\346\200\201.png" new file mode 100644 index 0000000000000000000000000000000000000000..c7d0a6e10e6e163bea2274c35a695e072d23fa05 Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\345\271\264\347\232\204\347\224\237\346\200\201.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\346\240\207\345\207\206\345\237\272\344\272\216_ISA_\347\232\204\344\277\241\346\201\257.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\346\240\207\345\207\206\345\237\272\344\272\216_ISA_\347\232\204\344\277\241\346\201\257.png" new file mode 100644 index 0000000000000000000000000000000000000000..c559491fadbd1e53ba447309224e6a94f2d95bf5 Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\346\240\207\345\207\206\345\237\272\344\272\216_ISA_\347\232\204\344\277\241\346\201\257.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\347\232\204\346\227\266\351\227\264\347\272\277\345\217\212\347\254\254\344\270\200\346\254\241.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\347\232\204\346\227\266\351\227\264\347\272\277\345\217\212\347\254\254\344\270\200\346\254\241.png" new file mode 100644 index 0000000000000000000000000000000000000000..8412439e38fbd059398ad492c1057a9635c8a06b Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\347\232\204\346\227\266\351\227\264\347\272\277\345\217\212\347\254\254\344\270\200\346\254\241.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_1_2016_\345\271\264.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_1_2016_\345\271\264.png" new file mode 100644 index 0000000000000000000000000000000000000000..97e9ac4ae711cbc50eacfb1140dd1137d852f42a Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_1_2016_\345\271\264.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_2_2016_\345\271\264.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_2_2016_\345\271\264.png" new file mode 100644 index 0000000000000000000000000000000000000000..9571bf8dea806e3542167669fc29dd06fe21ec18 Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\350\203\214\345\220\216\346\224\257\346\214\201\350\200\205_2_2016_\345\271\264.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\350\231\232\346\213\237\345\214\226\345\240\206\346\240\210.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\350\231\232\346\213\237\345\214\226\345\240\206\346\240\210.png" new file mode 100644 index 0000000000000000000000000000000000000000..4870751ad023673900bce56947663bf3db10db27 Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/RISC-V_\350\231\232\346\213\237\345\214\226\345\240\206\346\240\210.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/\344\274\257\345\205\213\345\210\251\345\244\247\345\255\246\346\240\270\345\277\203\347\256\200\350\246\201\345\216\206\345\217\262.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/\344\274\257\345\205\213\345\210\251\345\244\247\345\255\246\346\240\270\345\277\203\347\256\200\350\246\201\345\216\206\345\217\262.png" new file mode 100644 index 0000000000000000000000000000000000000000..4fc0265d38e1a0f3b3b6f848ac351b506f458023 Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/\344\274\257\345\205\213\345\210\251\345\244\247\345\255\246\346\240\270\345\277\203\347\256\200\350\246\201\345\216\206\345\217\262.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/\345\206\205\345\255\230\346\230\240\345\260\204.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/\345\206\205\345\255\230\346\230\240\345\260\204.png" new file mode 100644 index 0000000000000000000000000000000000000000..b728d0d9df78ddd638d8c13985146324cfd40c80 Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/\345\206\205\345\255\230\346\230\240\345\260\204.png" differ diff --git "a/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/\345\234\250_Linux_\344\270\255\345\220\257\345\212\250_QEMU_\344\270\255_RISC-V.png" "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/\345\234\250_Linux_\344\270\255\345\220\257\345\212\250_QEMU_\344\270\255_RISC-V.png" new file mode 100644 index 0000000000000000000000000000000000000000..c62daa81f43c84fe872fd5356621ef6c75237860 Binary files /dev/null and "b/articles/images/qemu_support_for_the_rsic-v_Instruction_set_architecture/\345\234\250_Linux_\344\270\255\345\220\257\345\212\250_QEMU_\344\270\255_RISC-V.png" differ