Intel 82599 ixgbe & ixgbevf CNA 卡驱动分析01——SR-IOV

转载自：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