SR-IOV

摘要： 介绍SR-IOV 的概念、使用场景、VMware 和 KVM 中的配置方法。

第一部分：

生产业务中，我们在虚拟化平台中遇到了部分虚拟机在业务高峰的时候，出现高延迟的情况。排查问题的时候，确认了两种情况，1是Hypervisor 的延迟是正常的， 2是GuestOS 内部的延迟也是正常的。所以判断应该是Hypervisor和GuestOS 之间的通信出现了问题。这时候想到了SR-IOV，想看看SR-IOV 能不能提供低延迟提供给对延迟敏感的业务。

写这篇文章之前，正好看到Red Hat 发布了 Red Hat Virtualization V4版，官方文档中，专门有一篇《Hardware considerations for implementing SR-IOV with Red Hat
Virtualization》。文章很短，主要介绍Red Hat Virtualization 中使用SR-IOV的前提条件：

• CPU 必须支持IOMMU（比如英特尔的 VT-d 或者AMD的 AMD-Vi，Power8 处理器默认支持IOMMU）
• 固件Firmware 必须支持IOMMU
• CPU 根桥必须支持 ACS 或者ACS等价特性
• PCIe 设备必须支持ACS 或者ACS等价特性
• 建议根桥和PCIe 设备中间的所有PCIe 交换设备都支持ACS，如果某个PCIe交换设备不支持ACS，其后的所有PCIe设备只能共享某个IOMMU 组，所以只能分配给1台虚机。

Red Hat 虚拟化平台V4 先介绍到这里。

第二部分：

现在介绍一下IO 虚拟化。IO 虚拟化目前主要也是分为3种， 第一是全虚拟化，通过VMM来模拟IO设备实现，VMM截获GuestOS的IO请求，通过软件模拟真实的硬件。VMM必须处理所有虚机的IO请求，然后将所有的IO情况序列化为可以被底层硬件处理的单一IO流。好处是GuestOS不需要考虑硬件设备的情况。问题是效率相对较低。例如 qemu。

第二种是IO半虚拟化技术。通过前端和后端模拟实现虚拟化。GuestOS中的半虚拟化驱动为前端，VMM 提供的与GuestOS 通讯的驱动程序为后端。前端驱动将GuestOS的请求通过与VMM之间的特殊通信机制发生给VMM后端需求，后端驱动处理完IO请求之后再发送给物理驱动。全虚拟化为了完成一次操作要涉及到多个寄存器的操作，使得VMM要截获每个寄存器访问并进行相应的模拟，就会导致多次上下