转载自:http://www.cnblogs.com/zhuyp1015/archive/2012/08/23/2653264.html
Intel 82599 ixgbe & ixgbevf CNA 卡驱动分析01——SR-IOV
SR-IOV Overview:
当在主机接口之后使用普通共享设备时,本地共享设备会为每个接口提供单独的内存空间,工作队列,中断和命令处理。这些共享资源也需要被管理,它们会向Hypervisor中可信分区提供一系列用于管理自己的寄存器。
当拥有独立的工作队列和命令处理机制后,这些设备就可以同时从多种资源接受命令,并将这些命令智能的融合在一起,在传递给下一级结构之前。
虚拟化软件不用再对I/O请求进行复用,这减少了软件的压力。
本地共享设备能够通过很多方式实现,可以按照标准实现也可以使用其他专门的实现方式。
因为大多数这些设备都是通过PCI 访问的,PCI-SIG 决定定义一种实现标准用语创建和管理本地共享设备,也就是现在的Single Root I/O Virtualization 和 Sharing (SR-IOV) specification.
SR-IOV Goal
PCI-SIG SR-IOV 标准目的在于标准化化在虚拟环境中共享一个 I/O 设备的方式。
这个目标绕开了Hypervisor 的参与,提供了独立的内存空间、中断、DMA 流给每一个虚拟机用于数据的移动。
SR-IOV 引入了两种新的function 类型:
Physical Function(PF):这是一个拥有所用PCIe 功能的fucntion,当然也包含了SR-IOV 扩展的能力
Virtual Function (VF): 这是一个轻量级的PCIe function,包含了数据移动所需的资源。
High Level Overview of PCI-SIG SR-IOV
虚拟化方法中的直接赋值提供了非常快速的I/O。 然而,这种方式使得I/O设备不能被共享。SR-IOV 标准提供了一个机制,通过这个机制使得一个单根的功能模块(比如一个以太网端口)看起来像是多个单独的物理设备。
一个支持SR-IOV 的设备能够通过配置(一般由Hypervisor来配置)在PCI的配置空间看起来像是拥有多个功能。每个功能都拥有自己的配置空间,拥有自己的基地址寄存器(BAR)。
支持SR-IOV 的设备为每个独立的虚拟功能提供了一个配置号,每个虚拟空能都拥有独立的PCI 配置空间。 Hypervisor 可以将一个活多个虚拟功能分配给一个虚拟机。内存地址翻译技术比如Intel VT-d 提供的硬件辅助技术使得可以针对每个虚拟机进行DMA传输。
SR-IOV 标准详细列出了PCI配置空间信息该如何呈现。这些信息与标准PCI设备的信息有些不同。Hypervisor必须知道如何访问和读取这些信息,以便使得VM可以访问它们。
High Level Architecture:
在虚拟化的环境中,系统中包含SR-IOV设备,Hypervisor都必须将PCI 配置空间的信息传递给虚拟机的I/O设备。对于SR-IOV 来说,Hypervisor 将实际的配置空间信息传递给特定的VF,允许虚拟机中的VF 驱动访问这些VF资源。
SR-IOV标准的一部分规定了一个支持SR-IOV的设备需要如何表明自身具有SR-IOV的能力,PCI配置空间的虚拟VF信息是如何被存储,可以怎样被访问。这是SR-IOV特有的机制。Hypervisor必须知道如何读取和分析这些信息。Linux和Xen内核已经更新,现已能够使用这项新功能。
VT-d 使得一个I/O设备通过DMA重映射操作可以直接分配给一个虚拟机。Hypervisor 必须使用I/O地址来进行配置,以便进行重映射。
注:1. 文章其实是对 Intel 提供的文档和代码的理解和翻译,
2. 这里没有讲SR-IOV具体是一个什么东西(或者说讲的太简略),如果有一定基础的朋友会知道,之后可能有会有专门的文章补充介绍
make it simple, make it happen