rIOMMU：Efficient IOMMU for I/O Devices that Employ Ring Buffers

文章内容理解

作者写作背景

在I/O设备开始与CPU异步直接与主存交换信息（DMA时代）开始时，DMA使用物理地址直接存取，这就给系统带来了很多诸如劣质甚至恶意设备影响，造成系统崩溃……等麻烦，在这种情况下，对I/O设备的存取统一管理的单元——输入输出存储管理单元（IOMMU）应运而生。随着设备带宽的提高，那些像网卡和PCIe SSD控制器等高带宽设备可以与系统通过一个环型缓冲器相互影响，于是一种带有环形的缓冲器能够分层、平滑地替换虚拟地址的rIOMMU成了研究的重点。这种rIOMMU能高达7.56倍地提高普通IOMMU的效率，是没有IOMMU的0.77—1.00倍。

文章结构

该文章从以下七个部分论述：

• 摘要：简述本次论文的主要内容；

• 介绍：向读者介绍什么是IOMMU以及什么是Riommu其他缩写的概念；

• 背景：在什么情况下，作者提出用rIOMMU改进原有IOMMU的：

  • 首先讲OS的DMA保护；
  • 接着讲IOMMU的设计与提升作用；
  • 最后提出rIOMMU的概念。

• 安全代价：讲解OS与IO设备的关系与保护方式

• 设计：这是作者主要论述的部分，也是本文的核心，从以下三个方面论述：

  • 数据结构
  • 硬件实现
  • 软件实现

• 评估：从7个模式分别测试该设计的可行性，又分为方法与结果两个部分论述

• 总结

下面直接进入文章的设计部分：

数据结构

作者从软件、硬件两种方式来组合实现rIOMMU,所以数据结构不得不是最先介绍的东西了。我将以代码与文字结合的方式介绍：

以上四个结构体所展示的数据结构，都是硬件软件公用的，他们都被rIOMMU用来转换虚拟地址，被操作系统调用。接下来定义一个只有硬件会使用的结构体：

## 硬件处理

首先，在与rRING相连的rIOTLB_entry的IOVA中寻找e，如果e不存在rIOMMU就搜索表，用上面定义的数据结构，找到rPTE，并插入rIOTLB一个匹配的entry，同时使表移动确保e.rpte是rPTE中给定的rIOVA。

其次，如果e已经初始化在rIOTLB被找到，rIOMMU匹配每一个IOVA和e，并且实时更新e。

然后，检查IOVA.offset如果出错，会造成rIOMMU启动I/O默认页（IOPF）,当然这并不是所希望的，未出错时，最终该offset会加到rPTE.phys_addr上形成虚拟地址的转换。

最后还有关于错误的一些处理，在此不再赘述。

软件处理

说完了硬件上的处理，接下来该软件上的操作了，说是软件其实就是设备的驱动程序、映射函数等底层的软件，这部分的处理和Linux中IOMMU的基准处理相似。

这一部分主要是处理映射的问题，具体就是将数据结构中定义的每个结构体的各个域之间建立联系。映射给每个设备一个ring ID，一个映射的物理地址，它包含两个部分：

1. 在ring的尾部分配一个环入口rPTE，然后更新上面数据结构提到的tail/nmapped域；
2. 当rPTE初始化后，首先确保其内容更新对rIOMMU是可见的，它的返回状态是入口的索引，而且这个ring ID是由IOVA所得到的。

这一部分也同样有错误处理，在此不再赘述。

可行性分析

可行性评估

在读了这一篇关于优化IOMMU的文章后，我在网上寻找了一下，相关的研究进展情况，发现早在很多年前像Intel、AMD等处理器生产商早就有关于IOMMU的应用，但是在像本文所讲的rIOMMU还没有得到应用过，也就是说文章现在所言皆是理想的情况。

在文章的后半部分，作者也从“方法”、“实验执行”、“基准”等方面做了很多测试，其中在“方法”模块采用：①strict，②strict+，③defer，④defer+，⑤riommu-，⑥riommu，⑦none其中模式，可以说是比较准确的了下图及下表展示所有测试结果：

通过结果可见，当运行“需求-响应”（RR）模式是，相对于普通IOMMU，提升不是多么的明显，但是在其他方面，结果还是挺理想的。

创新之处

作者在测试部分将模拟方法分成7个等级，基本上模拟了所有的正常可能情况，有力证明了本次实验的成功。

作者在进行设计之初，分析了现有的DMA与IOMMU，然后提出自己的设计，使我们对总体设计有一个整体认识，也使的作者的设计比较容易接受。

在设计上，作者不仅考虑到硬件，同时对软件也进行了设计，而且设计过程相当明细，用实际的代码来解释，使设计极具可行性。

设计存在的不足分析

• 我认为作者在设计时并未考虑这样设计所带来的结构复杂性，也未对实际的能耗做评估，也许可能会由于总线分配问题而没法嵌入系统。
• 作者虽然提到rIOMMU在对有错误的DMA设备的保护的作用，但是没有给出具体的保护方案。
• 我想到既然通过环形缓冲器能解决速度的问题，那么会不会带来其他的弊端，例如：某次传输没有传输完就被后一次的覆盖掉或者当环形缓冲器中有错误，没法处理时会不会发生DMA总是在那里占用总线而又没有实际的数据传输。
• 既然是环形缓冲器，那么当传输数据是暂时性的，而且又没能在有效的时间范围内进入环形缓冲器，那么是不是就有冲掉的风险。

针对不足的改进意见

在上一部分我浅显地提出了自己认为是不足的地方，在此仅仅做些自己认为合理的改进意见。不能保证我的观点是完全正确，但是这确实是我自己对相关问题的认识所得。

1. 作者可以增加关于能耗的测试，作者提到这样的rIOMMU确实在某些方面比IOMM要有效得多，但是能耗是不是也如此呢？作者应该往这方面做些必要的测试（由于水平有限，所以只能借助作者之手完成这项测试）。
2. 既然rIOMMU对设备有保护作用，那么其作用具体体现在哪呢？仅仅是在对错误数据的处理上，远远不足以满足现在设备的要求，例如，当某设备出错，重复发送某信息时，作为向主存传输信息的接口，应该如何处理呢？我认为可以从软件上进行相关判断，我觉得这将是这类IOMMU值得改进的地方。
3. 我觉得环缓冲器还应该增加错误信息清除能力，当出现出错信息时，能有效地将其清除并且不影响其他设备的正常传输。
4. 每个环形缓冲器都会有数量“size”的限制，像用尽这种现象应该是尽量避免的。也许可以通过取一个大大的“buffer”值来基本解决这一问题，但是将造成空间消耗严重，我觉得更好的解决办法是，修改设计，使设计能够容纳多个环缓冲器，当然不是每个环每次都会使用，当第一个环占满并且还有数据需要缓冲时，才会调用第二个环……在这种设计上，我觉得将会增加很多判断，设计空间的动态分配等问题。

附录

在此将本文所有用到的英文缩写做一下梳理：

• IOMMU: Input/Output Memory Management Unit 输入输出存储管理单元

• rIOMMU: IOMMU Employed Ring Buffers 带环缓冲器的IOMMU

• IOTLB: I/O Translation Lookaside Buffer 用于IOMMU的块表

• IOVA: I/O Visual Address IO虚拟地址

The link of this page is https://blog.nooa.tech/articles/51c782dd/ . Welcome to reproduce it!