RISC-V 双周简报 (2018-11-18)

要点新闻：

RISC-V Reader中文版发布
RISC-V芯片一个接着一个

RV新闻

RISC-V Reader的中文翻译版发布

由David Patterson, Andrew Waterman撰写的《RISC-V手册：一本开源指令集的指南》近日由包云岗老师带领的团队翻译完成。并在杭州互联网大会上CRVA成立仪式上发布，David Patterson现场也做了签名赠书活动。这本书的中文翻译目前以CC-BY-NC-SA 3.0 License发布。鼓励读者们对翻译做出改进，提交PR即可。

Links:

《RISC-V手册：一本开源指令集的指南》pdf版本下载
翻译的Github Repo：Lingrui98/RISC-V-book

方之熙博士被任命为RISC-V基金会中国顾问委员会主席

方之熙博士最近在互联网大会上被RISC-V基金会任命为中国顾问委员会主席，帮助加速RISC-V ISA在中国的应用。

方博士目前担任致象尔微电子科技（上海）有限公司(Tangram Technologies Inc.)首席执行官。在这之前他曾担任英特尔(Intel)副总裁。在英特尔任职期间，方博士主持创立了英特尔中国研究院(Intel Labs China)并担任院长。

Link: 方之熙博士被任命为RISC-V基金会中国顾问委员会主席，加速RISC-V ISA在中国的应用

RISC-V Tokyo Day 后续报道

上月在东京RISC-V Day Tokyo也得到了日本各媒体的广泛关注。其中在谈到ARM和Esperanto在数据中心市场的竞争时，Hisa Ando评论道。

Armでさえもデータセンター市場への食い込みには苦戦している状況であり、EsperantoのRISC-Vプロセサにとっても難しい戦いになると予想される。しかし、Esperantoのシステムは4Kコアという大量のMinionコアでAI処理を行うというものである。また、MinionはAI専用ではなく、汎用のアクセラレータコアであり、他の用途にも進出が可能である。このような特徴を生かしてのEsperantoの健闘を祈りたい。

Links:

产品和市场

SiFive发布7系列处理器家族

SiFive最近发布了其最新的7系列处理器家族，希望以此系列应用于5G、网络、存储、AI以及传感器融合等领域。

这几款处理器对标的对象很明确，分别是A55、M7和R8。据称这个系列的处理器皆为64-bit 8级流水线按序单发射。

大家也可以尝试下SiFive的在线处理器设计工具，定制你所需要的CPU Core。https://www.sifive.com/core-designer

新的7系列IP包含：

U74 — Linux-ready, Cortex-A55 like, 2.5 DMIPS, single-core with 128KB L2
U74-MC — Linux-ready, Cortex-A55 like, 2.5 DMIPS, quad-core with 2MB L2 and S7 monitor chip for real-time
E76 — Cortex-M7 like, 2.3 DMIPS, single-core
E76-MC — Cortex-M7 like, 2.3 DMIPS, quad-core with 2MB L2
S76 — Cortex-R8 like, 2.5 DMIPs, single-core
S76MC — Cortex-R8 like, 2.5 DMIPs, quad-core with 2MB L2

Links:

Esperanto融资B轮 5800万美金

Esperanto近日完成了其B轮融资5800万美元，将通过7nm RISC-V处理器ET-Maxion争夺AI芯片市场。Esperanto背后也有西部数据的强力支持。

Link: Esperanto Technologies Secures $58 Million in Series B Investment for AI Chip

睿思芯科推出基于RISC-V的64位可编程终端AI芯片Pygmy

硅谷OURS公司的中资RISC-V技术公司睿思芯科，由U.C. Berkeley校友谭章熹创立。其最近推出了其AI芯片Pygmy。

生态系统

中国开放指令生态（RISC-V）联盟(CRVA)成立

中国开放指令生态（RISC-V）联盟8日在浙江乌镇召开的世界互联网大会上成立。该联盟旨在推动建立世界共享的开源芯片生态。

联盟发起单位包括中科院计算所、北京大学、清华大学、阿里-中天微、百度、中芯国际等近20家研究机构和企业。

Links:

EDA+云计算碰撞出新火花

所谓交叉领域出成果，各大EDA和Fab厂都在积极的推荐EDA在云计算平台上的开花结果。当然机密数据的安全性依然是最大的顾虑，但有需求就会有创新，随着时间的推移很多问题都会找到答案。

由Cadence以及Synopsys个别经营的台积电OIP VDE虚拟店面都已经上线，其中Cadence的Cloud-Hosted Design Solution已有成功的设计定案完成，是与微软以及台积电的IP联盟伙伴SiFive合作，由分别位于印度与美国的设计团队共同在微软Azure上的VDE完成64位多核心RISC-V架构CPU设计，可用于执行RISC-V的Linux操作系统和相关应用程序。

Link: IC设计迈向云端新时代

技术讨论

如何在RV32中让M模式访问超过4GB的内存

在使用RV32的处理器中，M模式默认运行在32位的物理地址寻址模式中。32位的物理地址可以访问的内存范围最大4GB。然而，RV32允许处理器使用大于4GB的物理内存。32虚拟地址可以被映射到超过32比特的物理地址范围。这边出现了一个问题，直接运行在32位物理地址的M模式如何能访问超过4GB的地址空间呢。

根据RISC-V特权指令集草案的设定，控制寄存器mstatus中的MPRV比特可以设定让M模式的程序使用MPP(陷入M模式之前的模式)所定义的寻址方式访问内存。如果MPP为S或者U模式，M模式则可以使用S/U模式的页表，通过虚拟地址寻址访问大于4GB的地址空间。

MPRV的定义实际上是为了支持另外一种更为常见的使用方式(Priv Spec 1.10 Section 3.1.9)：

The MPRV and MXR mechanisms were conceived to improve the efficiency of M-mode routines that emulate missing hardware features, e.g., misaligned loads and stores. MPRV obviates the need to perform address translation in software. MXR allows instruction words to be loaded from pages marked execute-only.

译：MPRV和MXR机制的定义是为了提升使用M模式代码来模拟硬件缺失的特性。比如，(使用M模式）来模拟硬件不能直接支持的非对齐数据读写。 MPRV使得M模式可以执行地址翻译(访问虚拟地址), MXR允许读取只可执行页中的代码(小编注：一般情况下读取指令是一个安全漏洞)。

For simplicity, MPRV and MXR are in effect regardless of privilege mode, but in normal use will only be enabled for short sequences in machine mode.

译：简单来说，MPRV和MXR机制是和优先级无关的。但是在通常情况下，它们只被M模式的代码短暂使用。

isa-dev上的讨论

有关 sfence.vma 在内核的使用方式

Alan Kao 在邮件列表里问道，一旦页表（page table）被修改，我们应该使用 sfence.vma 。这在内核里已经很有几个例子说明这点，例如：

alloc_set_pte (in mm/memory.c):
...
set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
/* no need to invalidate: a not-present page won't be cached */
update_mmu_cache(vma, vmf->address, vmf->pte);
... 

update_mmu_cache 这个函数最终会执行一条 sfence.vma 指令。

那是不是大多数情况下总是如此呢？Alan Kao 对此很感兴趣于是研究了一番。RV64 使用三级页表项（page table entry），分别是 pud， pmd 和 pte，于是他跟踪了下跟在 set_pud ，set_pmd，set_pte 后面的代码。结果是一些调用（calls）后面并没有跟着 sfence.vam。这是他们的问题（bugs）还是 Alan Kao 误解了这条指令呢？

Palmer Dabbelt 回复道，就上面具体的例子，看起来是个 bug：我们尝试为了 vmalloc 区域填满页表，但我们只是不断自陷（continue trapping）而没有一条 sfence.vma 指令。在进入（poking）页表和返回（sret）之间的路径非常短，不像是会存在一条 sfence.vma 指令，所以 Palmer 也不确定这怎么能正常运转（this could work）。

Palmer 列出了段代码复现了这个问题，详见

Link: sw-dev上的讨论

关于全局指针寄存器(gp)的使用

Jérôme Pouiller在邮件列表里问到关于全局指针寄存器(global pointer register)的使用问题。他说：如果不在gcc里声明使用全局指针寄存器（换句话说，没有在链接脚本中初始化__global_pointer$），他的’.text’部分的大小只增加了0.5％。但是换来的好处是可以将gp用作通用寄存器(小编按：在RISC-V的ABI规范里，通用寄存器x3被保留做gp)，从而更好地利用该寄存器。其他架构，例如IA64或者MIPS，在gcc提供了将gp用作通用寄存器的选项，但是RISC-V却没找到。

Jim Wilson回答了关于gp的使用问题。首先，编译器默认不使用gp寄存器：编译器假设gp是固定寄存器，即不可分配，永远不会在函数调用中保存或恢复。他建议Jérôme看看-ffixed-X, -fcall-used-X和-fcall-saved-X选项，是否可以更改此默认值。Jim觉得即便让gp变成-fcall-saved的寄存器也不太可行，因为编译器假定gp不是call-saved的。但是用-fcall-used应该是可以的。

Jim同时提到了将gp用作通用寄存器时潜在的问题。如果在gcc使用了-msave-restore编译选项，这可能会与gp产生冲突。再有，如果编译中使用了中断(interrupt)属性，那可能产生类似的问题，因为它假设gp永远不需要保存，甚至是在中断处理程序中。

Jim认为所有链接器在使用gp之前，都会检查gp是否已被设置好。所以如果Jérôme不设置__global_pointer$，应该不用担心链接器会使用gp，但是Jérôme必须确保没有别代码库或操作系统代码使用gp寄存器。

Link: sw-dev上的讨论

RISC-V规范中关于PMP(Physical Memory Protection)设计的缺陷

Michael Clark在邮件中说，在qemu中实现PMP的遇到问题。按照规范定义，实现PMP的时候发现，对于4k粒度需要掩蔽低10位，根据关于力度检测的评论，这就假设了位索引是0，这就需要检测粒度大小是8，但如果检测粒度不是4，我们无法将最低有效位区分为Base地址还是长度。 andrew做了回复，并在riscv-isa-manual上做了修改。具体的commit:

https://github.com/riscv/riscv-isa-manual/commit/cb4515bbd59218e23088c6fff0343dada1f4fa8e
https://github.com/riscv/riscv-isa-manual/commit/693ad48fc347bb613b95f6ebafc2e062428c5bd5

讨论后qemu具体实现如下 https://github.com/riscv/riscv-qemu/blob/qemu-for-testing/target/riscv/pmp.c

qemu相关的commit

https://github.com/riscv/riscv-isa-sim/pull/240#ref-pullrequest-363883457

Link: sw-dev上的讨论

是否新加一个状态寄存器记录时间偏移

Anup Patel在邮件中提到一个关于RISC-V中虚拟化模块的问题。在RISC-V的所有模式中(包括HS模式和VS模式)，使用rdtime指令都会获得相同的时间。这会在Guest/VM迁移中引起问题。因为如果Guest/VM在A机器中暂停并保存在磁盘，然后复制到B机器，当复制过来的Guest/VM启动来时，用rdtime指令你会忽然发生一个大的变化。Anup Patel建议新加一个叫”hstimeoff”的状态寄存器来解决这个问题。

通过Anup Patel,waterman,Christoph Hellwig,Paolo Bonzini, lk...@lkcl.net和Michael Clark的讨论，可以通过陷阱/中断+软件来实现，都觉得引入新的状态寄存器不是特别必须的。Anup Patel最后做了总结：

As far as bootloader goes, we can have more than one bootloader on any system with different roles.

For everyone’s reference, here’s what we typically have in ARM world: BL1 (ROM) - This firmware is part of on-chip ROM and it is first stage of secured booting BL2 (LOADER) - This firmware is authenticated and loaded by BL1. It typically runs from on-chip SRAM (usually small). Its prime responsibility is DDR init and loading BL31 and BL33 BL31 (RUNTIME) - This firmware provides platform specific runtime services such as PSCI (same as SBI in RISC-V world) BL33 (BOOTLOADER) - This is the final firmware and it is generally some open source bootloader (such as Uboot, UEFI, etc). its prime responsibility is to boot the OS or Hypervisor.

From the above BL1, BL2, and BL31 are the only ones that run in EL3/EL1-S of ARM (similar to M-mode of RISC-V world) whereas BL33 runs in EL2/EL1-NS (similar to HS-mode and VS-mode respectively)

The above boot sequence is proven in ARM world across SOC vendors and works well with virtualization too because BL33 can be re-used inside Guest/VM.

Drawing inspiration from the above, last stage bootloader in RISC-V world should run in S-mode without assuming whether it is HS-mode or VS-mode.

通过对ARM的设计来看，对RISC-V来说，末级引导装载程序应该只运行与S模式，而不管是HS模式还是VS模式

Link: sw-dev上的讨论

安全点评

又发现7个Spectre/Meltdown攻击变种

在11月13日上传至arXiv的新论文中，原Meltdown和Spectre攻击的发现者们，又报出了7个新的攻击变种。他们认为现在研究者对于预测执行所造成的危害仍然理解不够，对整个攻击面的了解不充分，现有的防御也只是防御了少数几个变种，不能完全防御所有的攻击变种。所以，他们针对预测执行做了一个系统性地分析，详细地分类所有可能的攻击方式，并在此过程中，发现了7个还未被发现地变种攻击。下图就是他们给出的变种分类树。

瞬态执行(transient execution)攻击分类

Link: arXiv上的文章

花边

C-Sky 32-bit自主架构进入Linux内核主线

C-Sky其自主的32-bit架构C-Sky V2进入了Linux内核主线。

Arnd Bergmann的做出了如下评论，尽管RISC-V的发展和前景非常好，但是我们仍需给其他创新留有一定空间。

One more general comment: I think this may well be the last new CPU architecture we ever add to the kernel. Both nds32 and c-sky are made by companies that also work on risc-v, and generally speaking risc-v seems to be killing off any of the minor licensable instruction set projects, just like ARM has mostly killed off the custom vendor-specific instruction sets already. If we add another architecture in the future, it may instead be something like the LLVM bitcode or WebAssembly, who knows?

Link: C-SKY Architecture Approved For The Linux Kernel, Might Be The Last New CPU Arch