Virtio：针对 Linux 的 I/O 虚拟化框架

Virtio：针对 Linux 的 I/O 虚拟化框架

使用 KVM 和 lguest 的半虚拟化 I/O

Linux 内核支持多种虚拟化模式，并且支持的数量随着虚拟化的进步和新模式的出现（例如 lguest）而增加。但是，让这些虚拟化模式能够在 Linux 之上运行之后，又如何让它们能够在 I/O 虚拟化方面利用底层内核呢？答案是使用virtio，它为 hypervisor 和一组通用的 I/O 虚拟化驱动程序提供高效的抽象。探索 virtio 并了解为什么 Linux 将成为最佳的 hypervisor。 

概而言之，virtio 是半虚拟化 hypervisor 中位于设备之上的抽象层。

Linux 是 hypervisor 展台。inux 提供各种 hypervisor 解决方案，这些解决方案都有自己的特点和优点。这些解决方案包括 Kernel-based Virtual Machine (KVM)、lguest 和 User-mode Linux 等。在 Linux 上配备这些不同的 hypervisor 解决方案会给操作系统带来负担，负担的大小取决于各个解决方案的需求。其中的一项开销为设备的虚拟化。virtio 并没有提供多种设备模拟机制（针对网络、块和其他驱动程序），而是为这些设备模拟提供一个通用的前端，从而标准化接口和增加代码的跨平台重用。

完全虚拟化和半虚拟化

让我们快速讨论一下两种类型完全不同的虚拟化模式：完全虚拟化和半虚拟化。在 完全虚拟化 中，来宾操作系统运行在位于物理机器上的 hypervisor 之上。来宾操作系统并不知道它已被虚拟化，并且不需要任何更改就可以在该配置下工作。相反，在 半虚拟化 中，来宾操作系统不仅知道它运行在 hypervisor 之上，还包含让来宾操作系统更高效地过渡到 hypervisor 的代码（见 图 1）。

在完全虚拟化模式中，hypervisor 必须模拟设备硬件，它是在会话的最低级别进行模拟的（例如，网络驱动程序）。尽管在该抽象中模拟很干净，但它同时也是最低效、最复杂的。在半虚拟化模式中，来宾操作系统和 hypervisor 能够共同合作，让模拟更加高效。半虚拟化方法的缺点是操作系统知道它被虚拟化，并且需要修改才能工作。

图 1. 在完全虚拟化和半虚拟化环境下的设备模拟

硬件随着虚拟化技术而不断改变。新的处理器通过纳入高级指令来让来宾操作系统到 hypervisor 的过渡更加高效。此外，硬件也随着输入/输出（I/O）虚拟化而不断改变（参见参考资料 了解 Peripheral Controller Interconnect [PCI] passthrough 和 single- and multi-root I/O 虚拟化）。

virtio 的替换者

virtio 并不是该领域中的唯一霸主。Xen 提供半虚拟化设备驱动程序，VMware 也提供 Guest Tools。

但是在传统的完全虚拟化环境中，hypervisor 必须捕捉这些请求，然后模拟物理硬件的行为。尽管这样做提供很大的灵活性（即运行未更改的操作系统），但它的效率比较低（参见图 1 左边）。图 1 的右边是半虚拟化示例。在这里，来宾操作系统知道它运行在 hypervisor 之上，并包含了充当前端的驱动程序。Hypervisor 为特定的设备模拟实现后端驱动程序。通过在这些前端和后端驱动程序中的virtio，为开发模拟设备提供标准化接口，从而增加代码的跨平台重用率并提高效率。

针对 Linux 的抽象

从前面的小节可以看到，virtio 是对半虚拟化 hypervisor 中的一组通用模拟设备的抽象。该设置还允许 hypervisor 导出一组通用的模拟设备，并通过一个通用的应用编程接口（API）让它们变得可用。图 2 展示了为什么这很重要。有了半虚拟化 hypervisor 之后，来宾操作系统能够实现一组通用的接口，在一组后端驱动程序之后采用特定的设备模拟。后端驱动程序不需要是通用的，因为它们只实现前端所需的行为。

图 2. virtio 的驱动程序抽象

注意，在现实中（尽管不需要），设备模拟发生在使用 QEMU 的空间，因此后端驱动程序与 hypervisor 的用户空间交互，以通过 QEMU 为 I/O 提供便利。QEMU 是一个系统模拟器，它不仅提供来宾操作系统虚拟化平台，还提供整个系统（PCI 主机控制器、磁盘、网络、视频硬件、USB 控制器和其他硬件元素）的模拟。

virtio API 依赖一个简单的缓冲抽象来封装来宾操作系统需要的命令和数据。让我们查看 virtio API 的内部及其组件。

Virtio 架构

除了前端驱动程序（在来宾操作系统中实现）和后端驱动程序（在 hypervisor 中实现）之外，virtio 还定义了两个层来支持来宾操作系统到 hypervisor 的通信。在顶级（称为virtio）的是虚拟队列接口，它在概念上将前端驱动程序附加到后端驱动程序。驱动程序可以使用 0 个或多个队列，具体数量取决于需求。例如，virtio 网络驱动程序使用两个虚拟队列（一个用于接收，另一个用于发送），而virtio 块驱动程序仅使用一个虚拟队列。虚拟队列实际上被实现为跨越来宾操作系统和 hypervisor 的衔接点。但这可以通过任意方式实现，前提是来宾操作系统和 hypervisor 以相同的方式实现它。

图 3. vital 框架的高级架构

如 图 3 所示，分别为块设备（比如磁盘）、网络设备、PCI 模拟和 balloon 驱动程序列出了 5 个前端驱动程序。每个前端驱动程序在 hypervisor 中有一个对应的后端驱动程序。

概念层次结构

从来宾操作系统的角度来看，对象层次结构 的定义如 图 4 所示。在顶级的是 virtio_driver，它在来宾操作系统中表示前端驱动程序。与该驱动程序匹配的设备由 virtio_device（设备在来宾操作系统中的表示）封装。这引用 virtio_config_ops 结构（它定义配置virtio 设备的操作）。virtio_device 由 virtqueue 引用（它包含一个到它服务的virtio_device 的引用）。最后，每个 virtqueue 对象引用 virtqueue_ops 对象，后者定义处理 hypervisor 的驱动程序的底层队列操作。尽管队列操作是virtio API 的核心，我还是先简单讨论一下新的发现，然后再详细探讨 virtqueue_ops 操作。

图 4. virtio 前端的对象层次结构

该流程以创建 virtio_driver 并通过 register_virtio_driver 进行注册开始。virtio_driver 结构定义上层设备驱动程序、驱动程序支持的设备 ID 的列表、一个特性表单（取决于设备类型）和一个回调函数列表。当 hypervisor 识别到与设备列表中的设备 ID 相匹配的新设备时，将调用probe 函数（由 virtio_driver 对象提供）来传入 virtio_device 对象。将这个对象和设备的管理数据缓存起来（以独立于驱动程序的方式缓存）。可能要调用virtio_config_ops 函数来获取或设置特定于设备的选项，例如，为 virtio_blk 设备获取磁盘的 Read/Write 状态或设置块设备的块大小，具体情况取决于启动器的类型。

注意，virtio_device 不包含到 virtqueue 的引用（但 virtqueue 确实引用了virtio_device）。要识别与该 virtio_device 相关联的 virtqueue，您需要结合使用virtio_config_ops 对象和 find_vq 函数。该对象返回与这个 virtio_device 实例相关联的虚拟队列。find_vq 函数还允许为virtqueue 指定一个回调函数（查看 图 4 中的 virtqueue 结构）。

virtqueue 是一个简单的结构，它识别一个可选的回调函数（在 hypervisor 使用缓冲池时调用）、一个到 virtio_device 的引用、一个到 virtqueue 操作的引用，以及一个引用要使用的底层实现的特殊 priv 引用。虽然 callback 是可选的，但是它能够动态地启用或禁用回调。

该层次结构的核心是 virtqueue_ops，它定义在来宾操作系统和 hypervisor 之间移动命令和数据的方式。让我们首先探索添加到或从virtqueue 移除的对象。

Virtio 缓冲池

来宾操作系统（前端）驱动程序通过缓冲池与 hypervisor 交互。对于 I/O，来宾操作系统提供一个或多个表示请求的缓冲池。例如，您可以提供 3 个缓冲池，第一个表示 Read 请求，后面两个表示响应数据。该配置在内部被表示为一个散集列表（scatter-gather），列表中的每个条目表示一个地址和一个长度。

核心 API

通过 virtio_device 和 virtqueue（更常见）将来宾操作系统驱动程序与 hypervisor 的驱动程序链接起来。virtqueue 支持它自己的由 5 个函数组成的 API。您可以使用第一个函数add_buf 来向 hypervisor 提供请求。如前面所述，该请求以散集列表的形式存在。对于 add_buf，来宾操作系统提供用于将请求添加到队列的virtqueue、散集列表（地址和长度数组）、用作输出条目（目标是底层 hypervisor）的缓冲池数量，以及用作输入条目（hypervisor 将为它们储存数据并返回到来宾操作系统）的缓冲池数量。当通过add_buf 向 hypervisor 发出请求时，来宾操作系统能够通过 kick 函数通知 hypervisor 新的请求。为了获得最佳的性能，来宾操作系统应该在通过kick 发出通知之前将尽可能多的缓冲池装载到 virtqueue。

通过 get_buf 函数触发来自 hypervisor 的响应。来宾操作系统仅需调用该函数或通过提供的 virtqueue callback 函数等待通知就可以实现轮询。当来宾操作系统知道缓冲区可用时，调用get_buf 返回完成的缓冲区。

virtqueue API 的最后两个函数是 enable_cb 和 disable_cb。您可以使用这两个函数来启用或禁用回调进程（通过在virtqueue 中由 virtqueue 初始化的 callback 函数）。注意，该回调函数和 hypervisor 位于独立的地址空间中，因此调用通过一个间接的 hypervisor 来触发（比如kvm_hypercall）。

缓冲区的格式、顺序和内容仅对前端和后端驱动程序有意义。内部传输（当前实现中的连接点）仅移动缓冲区，并且不知道它们的内部表示。

我们先来看下QUEM模拟I/O设备的基本原理和优缺点:

使用QEMU模拟I/O的情况下，当客户机中的设备驱动程序（device driver）发起I/O操作请求之时，KVM模块中的I/O操作捕获代码会拦截这次I/O请求，然后经过处理后将本次I/O请求的信息存放到I/O共享页，并通知用户控件的QEMU程序。QEMU模拟程序获得I/O操作的具体信息之后，交由硬件模拟代码来模拟出本次的I/O操作，完成之后，将结果放回到I/O共享页，并通知KVM模块中的I/O操作捕获代码。最后，由KVM模块中的捕获代码读取I/O共享页中的操作结果，并把结果返回到客户机中。当然，这个操作过程中客户机作为一个QEMU进程在等待I/O时也可能被阻塞。另外，当客户机通过DMA（Direct Memory Access）访问大块I/O之时，QEMU模拟程序将不会把操作结果放到I/O共享页中，而是通过内存映射的方式将结果直接写到客户机的内存中去，然后通过KVM模块告诉客户机DMA操作已经完成。

QEMU模拟I/O设备的方式，其优点是可以通过软件模拟出各种各样的硬件设备，包括一些不常用的或者很老很经典的设备（如4.5节中提到RTL8139的网卡），而且它不用修改客户机操作系统，就可以实现模拟设备在客户机中正常工作。在KVM客户机中使用这种方式，对于解决手上没有足够设备的软件开发及调试有非常大的好处。而它的缺点是，每次I/O操作的路径比较长，有较多的VMEntry、VMExit发生，需要多次上下文切换（context switch），也需要多次数据复制，所以它的性能较差。

再来看看半虚拟化virtio的基本原理和优缺点

其中前端驱动(frondend，如virtio-blk、virtio-net等)是在客户机中存在的驱动程序模块，而后端处理程序（backend）是在QEMU中实现的。在这前后端驱动之间，还定义了两层来支持客户机与QEMU之间的通信。其中，“virtio”这一层是虚拟队列接口，它在概念上将前端驱动程序附加到后端处理程序。一个前端驱动程序可以使用0个或多个队列，具体数量取决于需求。例如，virtio-net网络驱动程序使用两个虚拟队列（一个用于接收，另一个用于发送），而virtio-blk块驱动程序仅使用一个虚拟队列。虚拟队列实际上被实现为跨越客户机操作系统和hypervisor的衔接点，但它可以通过任意方式实现，前提是客户机操作系统和virtio后端程序都遵循一定的标准，以相互匹配的方式实现它。而virtio-ring实现了环形缓冲区(ring buffer),用于保存前端驱动和后端处理程序执行的信息，并且它可以一次性保存前端驱动的多次I/O请求，并且交由后端去动去批量处理，最后实际调用宿主机中设备驱动实现物理上的I/O操作，这样做就可以根据约定实现批量处理而不是客户机中每次I/O请求都需要处理一次，从而提高客户机与hypervisor信息交换的效率。

Virtio半虚拟化驱动的方式，可以获得很好的I/O性能，其性能几乎可以达到和native(即:非虚拟化环境中的原生系统)差不多的I/O性能。所以，在使用KVM之时，如果宿主机内核和客户机都支持virtio的情况下，一般推荐使用virtio达到更好的性能。当然，virtio的也是有缺点的，它必须要客户机安装特定的Virtio驱动使其知道是运行在虚拟化环境中，且按照Virtio的规定格式进行数据传输，不过客户机中可能有一些老的Linux系统不支持virtio和主流的Windows系统需要安装特定的驱动才支持Virtio。不过，较新的一些Linux发行版(如RHEL 6.3、Fedora 17等)默认都将virtio相关驱动编译为模块，可直接作为客户机使用virtio，而且对于主流Windows系统都有对应的virtio驱动程序可供下载使用。

virtio是对半虚拟化hypervisor中的一组通用模拟设备的抽象.该设置还允许hypervisor导出一组通用的模拟设备,并通过一个通用的应用程序接口(API)让它们变得可用.有了半虚拟化hypervisor之后,来宾操作系统能够实现一组通用的接口,在一组后端驱动程序之后采用特定的设备模拟.后端驱动程序不需要是通用的,因为它们只实现前端所需的行为.

注意，在现实中（尽管不需要），设备模拟发生在使用 QEMU 的空间，因此后端驱动程序与 hypervisor 的用户空间交互，以通过 QEMU 为 I/O 提供便利。QEMU 是一个系统模拟器，它不仅提供来宾操作系统虚拟化平台，还提供整个系统（PCI 主机控制器、磁盘、网络、视频硬件、USB 控制器和其他硬件元素）的模拟。

示例 virtio 驱动程序

您可以在 Linux 内核的 ./drivers 子目录内找到各种前端驱动程序的源代码。可以在 ./drivers/net/virtio_net.c 中找到virtio 网络驱动程序，在 ./drivers/block/virtio_blk.c 中找到 virtio 块驱动程序。子目录 ./drivers/virtio 提供virtio 接口的实现（virtio 设备、驱动程序、virtqueue 和连接点）。virtio 还应用在 High-Performance Computing (HPC) 研究中，以开发出通过共享内存传递的 inter-virtual machine (VM) 通信。尤其是，这是通过使用virtio PCI 驱动程序的虚拟化 PCI 接口实现的。

现在，您可以在 Linux 内核中实践这个半虚拟化基础架构。您所需的包括一个充当 hypervisor 的内核、一个来宾操作性内核和用于设备模拟的 QEMU。您可以使用 KVM（位于主机内核中的一个模块）或 Rusty Russell 的lguest（修改版的 Linux 来宾操作系统内核）。这两个虚拟化解决方案都支持 virtio（以及用于系统模拟的 QEMU 和用于虚拟化管理的libvirt）。

Rusty 的 lguest 是针对半虚拟化驱动程序和更快速地模拟虚拟设备的更简洁代码库。但更重要的是，实践证明 virtio 比现有的商业解决方案提供更出色的性能（网络 I/O 能够提升 2-3 倍）。性能的提升是需要付出代价的，但是如果您使用 Linux 作为 hypervisor 和来宾操作系统，那么这样做是值得的。