浅谈早期 Fault Tolerance 虚拟机原理

背景 最近遇到了一些灵车硬件损坏问题，包括自己的台式机 13900K CPU 突然死机后重启就出现 CPU soft lockup，再重启直接无法点亮；自己的旧台式机出现 Correctable ECC 报错（感谢AMD消费级CPU也部分支持ECC）；以及一台别人的服务器上解压tar.gz包出现了CRC错误。一周内的这些经历使我开始思考云计算场景如何Tolerance这些奇怪的硬件损坏问题，于是看到了一篇VMWare vSphere 4（2010）年代的论文——The Design of a Practical System…

让Thunderbolt可以使用更大的BAR

问题描述 在Xilinx 7-Series FPGA上用AXI Memory Mapped to PCI Express IP核设置了一个256M的BAR，这个BAR直接连接到主板的PCIe上可以正常进行MMIO，但将FPGA通过Thunderbolt硬盘盒+M.2转PCIe连接到Thunderbolt上却无法使用。 通过查阅dmesg可观测到如下报错信息： [ 246.677146] pci 0000:0c:00.0: BAR 0: no…

Draco(MICRO’20) Architectural and Operating System Support for System Call Security 阅读笔记

要解决的问题 Linux内核提供了seccomp来对syscall权限进行检查，被广泛应用在容器、沙盒等多种场景，例如Docker和Android。但原版seccomp的实现是通过BPF对定义的规则一条条进行检查，如下图所示，十分低效： 同时，作者也进行了一系列的benchmark发现这样的检查带来了较大的开销： 其中，左边的docker-default指的是Docker默认使用的seccomp-profile，syscall-noargs指的是使application-specific profile但只检查syscall id而不检查参数，而syscall-complete就在noargs的基础上加上参数检查，最后加上-2x的后缀表示的是这些检查复制2次，来建模更复杂的安全检查场景。 可以看出，seccomp检查带来的开销即使是对于像nginx这样的macro-benchmarks也是比较大的，但现有的seccomp使用BPF，规则十分灵活，因此需要针对这种灵活的规则设计一种加速的方法。 Observation 检查系统调用ID会给Docker容器中的应用带来明显(noticeable)的性能开销。 检查系统调用参数比只检查系统调用ID的开销大得多(significantly more expensive)。 规则加倍，开销加倍。 syscall with 相同id和参数存在局部性（下图指明了实验中的距离） 解决方法 为了解决这个问题，作者引入了一个Fast…

聊聊内存序

最近读完了 A Primer on Memory Consistency and Cache Coherence这本书，写一篇文章结合我个人了解的其他知识总结一下内存序。 文章假定读者学习了基本的体系结构。 概念 Cache Coherence 相信大家对Cache有一个基本的理解。但这里需要引出一个新的概念，共享内存中的Private Cache。 即使是简单的单核处理器，往往L1 I-Cache与D-Cache也是Private的。因为IFU（取指单元）与LSU（访存单元）通常分布在处理器流水线的不同阶段，它们可能需要同时访问。既然是Private，这个时候如果我们通过访存指令写入了一些指令（通过D-Cache）到某个内存地址，而这个地址已经在I-Cache中，结果就在取指时有可能取到旧值，如何解决这一问题？ 也许L1…

在Xilinx FPGA上搭建SoC

背景 之前出于科研需求和龙芯杯比赛需求都自己搭建过SoC来运行CPU软核，整理一下我的搭建SoC的流程。以下的讨论基于MIPS和RISC-V两种软核ISA为例。 大家也可以参考我搭建的两个SoC以及对应的软件： cyysoc （RISC-V Rocket+Coherent DMA） pblaze_soc 某大船SSD上的xc7k325t-2 FPGA+2G 72bit DDR3 ECC 用了某个PCI-E引出到SFP接口的扩展板，连接光模块/电口模块提供网络 PCI-E和SFP的IO在FPGA上都是GTX 用了某个该板子的IO接口转USB UART的扩展板 扩展板上面还有rgmii…