大家好，今天小编来为大家解答浅谈Linux设备虚拟化技术的演进这个问题，很多人还不知道，现在让我们一起来看看吧！

Trap-and-emulate

在最早阶段，设备虚拟化通常与机器仿真器技术（例如QEMU）联系在一起。我们可以使用QEMU来模拟真实设备的所有寄存器布局和操作过程。当QEMU虚拟机中的设备驱动程序需要访问虚拟设备的寄存器时，这条访问指令会被捕获到QEMU，由QEMU来处理。这样，虚拟机中的设备驱动程序操作虚拟设备就像访问真实的硬件设备一样，设备驱动程序不需要任何改变。

Virtio

通过上述捕获和仿真方法来模拟器件。虽然不需要更改真实的设备驱动程序，但设备访问过程中频繁的陷阱和退出带来了严重的性能问题。因此， virtio 这种半虚拟化技术应运而生，并于2008 年被纳入Linux 内核主线。

与trap-and-emulate方法相比，Virtio不再依赖现有的设备驱动程序，而是定义了专用于虚拟设备的新驱动程序框架。设备驱动程序知道自己正在操作虚拟设备，因此可以避免在真实I/O 路径上进行大量可能导致陷阱的mmio/pio 操作，从而提高性能。虚拟机中的Virtio驱动与QEMU模拟的Virtio设备之间的数据交互本质上是基于共享内存+环形队列的通信机制。核心数据结构（split virtqueue）包括：两个ringbuffer（availring，usedring）和一个描述符表。工作机制与DMA类似。虚拟机中的virtio驱动首先会将内存中需要传输的哈希缓冲区的地址和长度写入描述符表中，然后将相应的描述符写入描述符表中。将索引写入可用环，并通过eventfd机制通知给主机上的virtio后端。由于这些ringbuffer、描述符表和hash buffer都在共享内存中（虚拟机本质上是一个用户态进程，所以虚拟机内存是由用户态申请和分配的，可以与其他进程共享，例如：SPDK、DPDK等），因此，Virtio Backend可以直接访问并获取哈希缓冲区的地址和长度，然后直接访问这些哈希缓冲区。 Virtio Backend处理完请求后，将数据填充到相应的缓冲区中，将相应的描述符表索引写入到使用的环中，并通过eventfd机制注入中断来通知虚拟机中的virtio驱动程序。

Vhost

引入Virtio技术后，Virtio设备通常是在QEMU中模拟的，数据的发送和接收需要经过QEMU再到虚拟机内部。但渐渐地，开发者发现，在QEMU中模拟网卡并发送和接收数据时，最终需要进行系统调用并落入内核来操作网卡硬件进行实际的数据发送和接收。那么，有没有什么方法可以优化从QEMU到内核的上下文切换及其带来的额外复制开销呢？

Linux内核社区最终在2010年纳入了vhost技术进行优化。通过将virtio 数据平面卸载到内核线程进行处理，virtio 通信机制从原来的QEMU 用户态I/O 线程和虚拟机驱动程序发生了变化。（QEMU 用户模式vcpu 线程）通信变成vhost 内核I/O 线程和虚拟机驱动程序（QEMU 用户模式vcpu 线程）之间的通信。 vhost内核I/O线程拿到数据包后，直接经过内核协议栈和网卡驱动进行处理，从而优化了从QEMU到内核态的额外开销。

VFIO

随着云计算规模的不断扩大，用户不再满足于Virtio等半虚拟化设备带来的性能体验。另一方面，GPU等难以virtio的设备的应用场景日益增多。在此背景下，VFIO技术被提出，并于2012年纳入Linux内核主线。VFIO的全称是Virtual Function I/O。它实际上是一个用户模式设备驱动框架。与早期的uio用户态设备驱动框架相比，VFIO可以有效利用硬件IOMMU机制进行安全隔离，因此可以广泛应用于具有多租户需求的云计算等场景中。

如上图所示，通过VFIO，QEMU可以直接打开虚拟PCI设备和物理PCI设备之间的数据链路。虚拟机中的设备驱动程序访问虚拟PCI设备的bar空间时，采用EPT机制，此时mmio访问将被重定向到真实物理设备对应的bar空间位置，无需再进行访问。陷阱到QEMU。这样虚拟机驱动就可以直接访问真实的物理设备，几乎零消耗，性能也能达到最优。同时，VFIO驱动程序使用IOMMU来实现设备DMA和中断重映射。一方面起到隔离作用，即虚拟机无法操作VFIO透传设备向同一主机上的其他虚拟机发起DMA和中断。另一方面，这也保证了设备在进行DMA时可以通过给定的虚拟机物理地址直接访问正确的物理内存。

Vhost-user

虽然VFIO 可以给虚拟机带来接近物理机的I/O 性能体验，但该技术仍然存在缺陷，即不支持实时迁移，带有VFIO 设备的虚拟机不会能够与传统virtio 设备一样执行。像虚拟机一样执行实时迁移。这促使开发人员开始探索新的设备虚拟化技术，既能满足性能需求，又能提供运维灵活性。 QEMU 社区于2014 年引入的vhost-user 技术就是其中之一。由于QEMU和vhost的线程模型对于I/O性能的优化并不友好，每个虚拟机都有自己独立的线程来处理I/O。从全局系统的角度来看，该方法可能不是最佳的。因此，vhost-user提出了一种新方法，即将virtio设备的数据面卸载到另一个专用进程来处理。这样，由于是专用进程，因此线程模型不再受传统QEMU和vhost线程模型的限制，可以任意优化。同时还可以1:M的方式同时处理多个虚拟机的I/O请求，并且相比vhost的内核线程模式让用户进程在运维方面更加灵活。 vhost-user框架自首次提出以来就受到了广泛关注，并催生了基于轮询+用户态驱动的SPDK和OVS-DPDK的推出。核心新的虚拟机I/O服务模型。

VFIO-mdev

VFIO技术在实际应用场景中，除了前面提到的不支持热迁移的问题外，另一个限制是一台设备只能透传到一台虚拟机，无法实现资源共享。 SR-IOV技术可以在一定程度上解决这个问题。它将物理PCI设备的资源从硬件层面划分为多个VF，透传给多个虚拟机使用。然而，许多设备可能不具备此功能。 SR-IOV能力，因此，Linux内核社区在2016年纳入了VFIO-mdev技术框架，希望提供一个标准接口来帮助设备驱动实现软件级资源分割，并利用VFIO技术透传给虚拟机。

该技术本质上是在内核中实现了一种虚拟设备（Mediated device）总线驱动模型，并在VFIO内核框架上进行了扩展，增加了对mdev（mdev总线驱动程序）等虚拟设备的支持。从原来支持从标准硬件PCI设备和硬件平台设备（如PCI bar space）获取透传信息，变成了既可以直接从硬件设备获取，也可以从mdev设备驱动定义的虚拟设备接口获取。这样，例如，如果需要将一个PCI 设备的bar 空间划分为资源，通过实现合适的mdev 设备驱动，可以将bar 空间以4KB（页大小）的粒度透明传输到不同的虚拟机。）。

vDPA

VFIO和virtio一直是最主流的设备虚拟化技术。 VFIO可以直接将硬件资源透明传输给虚拟机使用，性能最佳。 Virtio 的性能稍低，但更灵活。有没有可能结合两者的优点呢？ 2020年合并到Linux内核主线的vDPA技术框架就是为了实现这一目标。

vDPA的全称是Virtio Data Path Acceleration，它代表一类设备：该类设备的数据平面处理严格遵循Virtio协议规范，即驱动程序和设备将按照Virtio通信流程进行通信第3节中提到了，但是控制路径，例如：通信过程中提到的环形缓冲区和描述符表的内存地址，驱动程序如何通知设备，设备支持的功能以及驱动程序如何感知它全部由制造商定制，不一定遵循Virtio 协议。这样做的好处是可以降低制造商实施此类设备时的复杂性。

为了应用此类设备，Linux内核提出了vDPA等技术框架。这个技术框架本质上和VFIO-mdev类似。它还实现了虚拟设备（vDPA 设备）总线驱动程序模型。与VFIO-mdev不同的是，通过vDPA框架虚拟化的设备可以被虚拟机使用并直接从主机（例如容器）访问。这一切都是由于vDPA设备的数据路径遵循Virtio协议规范，因此可以被主机上的virtio驱动程序直接访问。同时，该技术框架扩展了vhost内核子系统，并给出了类似于VFIO技术框架的功能，使得vDPA设备进行数据通信所使用的硬件资源（环形缓冲区、描述符表、门铃寄存器等）能够被透传到虚拟，这样虚拟机的virtio驱动进行数据通信时，也是直接访问硬件资源，不再需要通过vhost、vhost-user等处理。更重要的是，由于虚拟机驱动是原来的virtio驱动，当需要支持热迁移时，QEMU可以灵活切换到软件模拟，保证热迁移的顺利进行。这样，vDPA这个设备虚拟化技术框架不仅在保留virtio设备灵活性的同时保证了最佳性能，而且统一了虚拟机和容器的I/O技术栈。

VDUSE

通过上面的vDPA技术框架，我们基本解决了设备虚拟化技术在虚拟机场景中长期暴露的一些问题，更重要的是，它把virtio技术带到了容器领域。不过这个技术框架还存在一个问题，那就是需要硬件设备的支持。回想一下之前提到的virtio、vhost 和vhost-user 本质上都是软件定义的虚拟设备。 vDPA的技术框架有没有可能也可以使用软件定义设备呢？ VDUSE技术就是用来实现这一目标的。通过VDUSE，我们可以在用户进程中实现软件定义的vDPA设备，并且可以通过上述vDPA框架访问virtio或vhost子系统以供容器或虚拟机使用。