要解决的问题 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…
基于PiKVM制作M1 Mac Mini KVM
背景 因科研需求，让实验室购买了一台M1芯片的Mac Mini进行相关测试。但由于我的操作会涉及大量Kernel Panic，且希望将机器丢在远端，因此需要有一种方法能够让我远程进行真机的键盘鼠标操作以及按电源键的操作。 相关工作 之前有了解到PiKVM项目，通过树莓派的OTG功能接上HDMI采集卡，就可以实现远程控制电脑的键盘鼠标，并可以自定义各种GPIO的设备，实现连接开关按钮、LED指示灯，甚至还支持伺服电机，能够直接连接机械手完成按电源键的操作。 此外，它还可以通过OTG模拟一个ncm/rndis网卡、USB串口、USB光驱、U盘等设备。但值得注意的是，这些设备在macOS与Linux中均可使用，但U-Boot不支持ncm/rndis网卡与USB串口，甚至打开后会导致U-Boot中无法使用PiKVM键盘控制（原因待研究）。 挑战 最大的挑战在于，Apple Silicon的Mac不再像之前的x86机器那样，通过按住键盘上的option就可以进入启动菜单，而需要长按电源键，这就给远程管理带来了困难。 受到twd2的这三篇文章启发（远程控制Apple M1 Mac Mini、制作Apple M1 Mac Mini远程控制装置、安装Apple M1…
浅谈现代处理器实现超大L1 Cache的方式
浅谈现代处理器实现超大L1 Cache的方式 昨天观看WWDC时看到Apple M2处理器的L1 Cache大小已经达到了192K+128K，这不禁使我产生好奇，Apple如何做到这一点。（尽管事后发现M1处理器已经实现了，但那时的我还不懂电路上的困难。） 超大L1 Cache是一件复杂的事情，对于L1 Cache，我们都希望它的访问延迟尽可能低。而由于我们目前的处理器和操作系统采用的虚拟内存分页机制，在使用虚拟地址访问内存时，需要首先得到对应虚拟地址的物理地址，这就导致在一条访存指令算出访存的虚拟地址后，我们首先需要查询TLB，而若查询TLB再将地址送入缓存，无疑增加了访问延迟。而对于许多高性能设计的处理器而言，L1 Cache的访问往往是制约处理器频率的主要关键路径，因此涉及到L1 Cache的电路路径都需要非常慎重考虑具体设计的路径长度。 基于目前CPU中的Cache主要采用组相连的结构，在该结构上解决方法通常采用VIPT的方式，即Virtually Indexed Physically Tagged。如下图所示，通过虚拟地址的一部分作为访问Cache的索引，同时将虚拟地址送入TLB中，这样我们就实现了电路上访问Cache与访问TLB的并行，在访问结束后对比TLB输出的物理地址高位与Cache访问得到的物理地址Tag，就完成了缓存是否命中的判断。 VIPT Cache在具体实现时，我们需要考虑缓存重名的问题。例如CPU上运行着2个进程有一个共享内存，这块共享内存对应着一块物理地址，但在2个进程中的虚拟地址不同，而如果CPU只是简单地将两份虚拟地址的数据都直接保存在缓存中，就会导致缓存不一致的问题。 SOTA的大部分处理器并未解决该问题（例如我们常见的Intel和AMD），只是将VIPT简化为伪VIPT。因为在许多ISA的虚拟内存管理中，最小页面大小为4KB，因此，我只需要保证作为Index的部分在虚拟地址的低12位内（即4KB内）即可。不过，这种方法导致L1 Cache中单路的大小无法超过MMU规定的最小页面大小，而组相连的场景下，随着路数增加，电路上判断并选择带来的电路长度也随之增加，同样提高了电路的延迟，导致频率的降低或划分流水线阶段后IPC（Instructions…
调试sfence.vma，12天之差错过Linux Patch一个
起因 最近造了个RISC-V CPU模拟器——CEMU，并实现了软件模拟TLB来加速地址翻译。而TLB和页表并不自带一致性，在RISC-V上需使用sfence.vma这样的指令来刷掉TLB和Page Table Cache（如果存在）和硬件流水线上的指令来确保页表修改生效。并通过了RISC-V Test中的所有测试，然而在启动Linux进入Busybox却遇到如下问题： 尽管Busybox能跑起来并正常使用，但同样的内核在qemu和Rocket上都是完全正常的，因此我继续探索了一下可能的问题。后来objdump了一下busybox的这个地址，发现是一条ret(jalr)指令，而跳转的地址是从栈上ld的。 因此我就怀疑是页表出现了问题导致fork的时候这个进程的栈对别的进程的栈产生了破坏。 第一次尝试 我首先怀疑了TLB查找出现问题，因此我修改了sfence.vma指令的实现，将sfence.vma实现为不管asid和va，全刷TLB，结果用户进程正常载入了。 后续继续做了些尝试，发现只要在执行sfence.vma的时候忽略ASID，但保留va的判断，用户进程依然正常运行。 第二次尝试 这次在实验室里twd2和dram一起来看我调试了。我在每次TLB Hit的情况下都重新进行一遍Page Table Walk，并检查Walk出来的PTE结果和TLB的区别。 结果发现Linux Kernel在一个Hart启动的时候会出现一次页表的W位不同的问题，但那是一条sfence.vma指令的fetch，所以没有对运行结果产生影响。…
U-Boot RISC-V M Mode的灵车SMP启动
为了方便运行任意M Mode软件，同时不想自制Bootloader。我决定在我的RISC-V SoC上使用M Mode U-Boot。然后再上面跑OpenSBI再把Linux作为OpenSBI的Payload运行。但U-Boot的go命令只会修改当前Hart的PC，并不会让其他Hart进行跳转。这就导致后续OpenSBI启动Linux一发送IPI就不断进入Trap Handler。 最后我想了个简单解决方法是，一旦进入Trap Handler且发现是当前无法解决的Trap就跳转到DRAM_BASE（也就是OpenSBI的TEXT段开始地址），并将a0寄存器设置上hartid（符合OpenSBI要求）。这样当IPI产生时其他核就会进入OpenSBI。配合Rocket Chip开双核，经过多次测试，Linux SMP均正常工作。不过比较灵车，理论上正确做法应该修改U-Boot代码控制其他核的IPI跳转。 修改在此：https://github.com/cyyself/u-boot/commit/c637a978068c434691899f1139b8b3e6c45efc93 在这种方法下，只需要保证设备树科学，然后使用u-boot通过tftp/串口将OpenSBI编译的fw_payload.bin载入到DRAM_BASE，然后使用go 0x80000000即可完成SMP启动。不过这种灵车做法需要确保的是，启动过程发送IPI之前不会对U-Boot使用的内存地址进行任何破坏。
修网（AXI Ethernet）
故障现象 今日发现我之前搭建的基于Rocket Chip的SoC，在U-Boot中网卡工作，但Linux中网卡一直无法工作。并发现经常在Linux中使用ip link set eth0 up在看到dmesg输出3行网卡开启信息后系统就卡死，并在reset核心后U-boot（XIP）载入到开始访问DRAM的位置就停下。看起来像是AXI总线上（因为我没有进行Reset）有请求在我reset期间没有完成，这大概可以说明AXI总线上发了一些核的Slave无法处理的请求。 起初我怀疑问题有一部分和中断有关，因为U-Boot没有使用中断，但通过检查/proc/interrupts发现连接在PLIC上两个网卡的中断号都能在set eth0 up后出现多次中断。然后看了下Linux的Documentation中的设备树相关部分，发现我的网卡中断和DMA中断设置不对（要求把DMA中断也放在网卡中断中，但实测是等价的），修改后问题依旧，按照一个别人能工作的设备树写法修改后问题依旧。 而继续搜索相关资料发现，别人遇到的问题多数都是PHY相关。然而我使用的是SFP接口的1000BaseX，AXI Ethernet会自己实例化一个PHY，并不是外置的。 解决方法 后来我对比了我的SoC和别人的SoC，发现我拖出来的AXI DMA IP核的Memory Map Data…
用Linux resctrl玩x86 CPU上的L3 CAT
最近基于Verilator框架写了一个SoC仿真器，用C++实现了AXI接口以便软件定义MMIO。然而写完后运行发现，它的速度确实比FPGA要慢上非常多，FPGA上几秒钟完成的事情用Verilator仿真可能要跑几分钟才能跑出来。而RTL仿真是对于CPU的Cache压力很大的应用场景，因此就玩了下Linux的resctrl进行测试。方便后续选购CPU。 Linux resctrl已经支持Intel和AMD处理器中的许多技术。包括常见到的用来共享隔离Cache缓解侧信道的Intel CAT技术。然而我手里的Intel 12900K通过查看/proc/cpuinfo发现它只支持L2 CAT。而自己的AMD 5800X却可以支持L3 CAT，因此就用它进行了测试。而resctrl的配置主要参考了User Interface for Resource Control feature。 首先，对于Kernel v5.0以上，需要在config中打开CONFIG_X86_CPU_RESCTRL。Debian已经默认打开。 然后，挂载resctrl文件系统： sudo mount…
Back to Top