SR-IOV（二）

SR-IOV的spec（《Single Root I/O Virtualization and Sharing Specification》）不仅对于SR-IOV的细节定义的很清楚，而且从架构上讲解了SR-IOV的演进过程。了解历史，更有助于我们理解技术细节。

     上图是一个典型的早期系统架构图。系统中只有一个根节点（Root Complex）用于扩展连接外部的设备。这些连接走的是PCIe协议，当然，RC可以直接连接外设（EP），也可以通过PCIe Switch扩展。（这部分内容是PCIe的基础协议，不了解的可以参考前期的文章《好大一棵树 – PCIe Tree》以及《从PCI角度认识PCIe》https://mp.weixin.qq.com/s?__biz=MzU4MTczMDg1Nw==&mid=2247483693&idx=1&sn=2c31665a69da49405d354844dd137134&chksm=fd42566bca35df7d65d68e9bb04f0ae22ff65fefbf4a51bab3be1ca3b6ba2e70b543d1228cce&token=1770615963&lang=zh_CN#rd）这里的SI（System Image）相当于操作系统。

     后面为了提高有效硬件资源利用率，引入了虚拟化技术，在不修改、增加硬件的前提下，软件模拟了硬件的行为。出现了一个软件的中间层Virtualization Intermediary (VI)，也就是虚拟化中间层。VI提供了对于底层硬件的抽象和访问控制，提供了某个硬件设备实例的虚拟化实例。因此，可以在VI之上安装更多的操作系统镜像或者虚拟机。

     如前一篇所述，这种情况下，所有的IO访问都要通过软件实现的VI统一调度和统一转发。因此，性能损失极大。在这种背景下，SR-IOV应运而生：

       首先我们注意到：传统的PCIe Device（EP）拥有了两中类别的功能（Function）：PF（Physic Function）和VF（Virtual Function）。。其中PF（图中的PF0）跟以前的Spec定义的PF一样，不同的是，支持SR-IOV的PF可以被系统配置为支持多个VF。当使能SR-IOV后，这个PF会生成多个VF（图中的VF1…VFn）。这些VF是可以被不同的操作系统（SI）来访问到的。对于SI或者应用程序来讲，访问这些VF和PF的方法一致，没有任何差异。注意，这个图中只显示了一个PF0，实际上，支持SR-IOV的PCIe Device是可以有多个PF存在的。

       其次，为了支持能够配置PF、管理PF、VF等，软件方面需要对应增加，这个部分叫：SR-PCIM（Single Root PCI Manager）。可以理解为系统的SR-IOV管理驱动。       

其他几个如：Address Translation and Protection Table（ATPT）、Translation Agent（TA）、Address Translation Cache（ATC）。这些都是有关PCIe设备地址翻译的问题，所谓地址翻译，是指存储地址空间到PCIe外设设备地址空间的转换。这部分内容不是我们当前内容考虑的重点，有兴趣的可以看看ATS的Spec（Address Translation Services Specification）。