上期我们在《虚拟化与云计算硬核技术内幕 (10) —— 事事有人管，人人有事管》中，为大家描述了如何将特定外设的中断送到指定的虚拟机的指定CPU上。那么，虚拟机的外设实际上到底是哪里来的呢？
在虚拟化技术诞生初期，虚拟机上的设备基本都是模拟(Emulate)出来的，用软件完全模拟硬件的行为。
下图中是Emulate模式虚拟IO各模块的关系：
为了让大家能更好理解，我们用一个栗子来解释：
在VMWare Workstation中，可以为虚拟机增加图形适配器(显卡)，虚拟机上的显示操作，都会通过虚拟的图形适配器最终显示到宿主机的桌面上来。
其中，GuestOS和图形适配器驱动没有做任何修改。假设QEMU为Guest OS模拟出来的图形适配器为Nvidia Riva-128 (知道这个的都暴露年龄了)，Guest OS依然调用Nvidia Riva-128 的驱动，通过IO指令向虚拟的图形适配器发出IO操作。
但由于实际上这个操作是在虚拟机中，IO指令会让GuestOS发生VM_Exit，并退回到KVM中。
KVM提供的模拟设备驱动程序会处理这一系列IO操作，并最终调用宿主机真实的GPU(方老师使用的是Intel核芯显卡Iris，穷)，最终在桌面上显示虚拟机的终端。
可想而知，操作系统对这种虚拟外设的每次IO操作，都需要宿主机的VMM帮助完成，其工作效率是非常低下的。
以QEMU为代表的Linux虚拟化采用了另一种方案：半虚拟化。
半虚拟化指的，将虚拟的外设分拆为两部分。一部分是可以在虚拟机上安装的虚拟化设备驱动，另一部分在VMM中。
这相当于为Guest OS系统中发明了一个新的设备，Guest OS看到的这个设备实际上会通到VMM中。每次GuestOS对这个设备进行操作，会直接调用VMM为其提供的代码(又称为前端驱动，Front-end driver)，在这段代码中调用真实的设备驱动(又称为后端驱动，Back-end driver)完成IO操作。
让我们举一个栗子：
在Linux下，通常以块设备的方式管理存储设备，对磁盘文件系统上的操作最终会调用块设备驱动实现。
VMWare Workstation中，虚拟机的块设备，在默认模式下实际上是VMDK文件，VMM会通过Emulate的方式，拦截虚拟机的磁盘IO操作，最终在VMDK文件中落盘。然而，在KVM中，除了使用这种本地磁盘外，更常见的方式是使用虚拟化的分布式存储。
我们在《云存储硬核技术内幕——(6) 面壁十年 邃密群科》中提到过，在KVM中，可以通过直接挂载RBD块的方式，让虚拟机将Ceph的RBD块作为一个块设备(如/dev/vda1 这样的设备) 使用，如下图所示：
也让我们再次重温一下KVM下，Linux虚拟机将数据写入Ceph RBD块的工作过程：
- GuestOS操作系统调用/dev/vda1设备驱动，向指定的LBA号发出读写请求；
- /dev/vda1 设备驱动实际上是Ceph的RBD驱动，也就是所谓的前端驱动。它会向宿主机上Linux操作系统上的后端驱动发起写请求；
- 宿主机上Linux操作系统上的后端驱动调用系统的TCP/IP协议栈，向Ceph实际的存储节点写入数据；
在这个过程中，我们发现，前端驱动运行在虚拟机中，而后端驱动运行在宿主机上。如果前端驱动在每次IO操作时，都要通过触发VM_Exit来切出虚拟机，然后调用后端驱动中的代码实现操作真实的硬件，那么，这种半虚拟化工作模式和前面提到的全虚拟化(Emulate)区别也就不大了。
Linux和KVM的工程师们给出的解决方案是，为前端驱动和后端驱动制定一种通信规范。这种通信规范就叫做Virtio。
Virtio为前端驱动和后端驱动创建了一个队列(Queue)式的通信管道，称为Virtqueue。Virtqueue中，传输的是Guest OS与Host OS之间交互的数据结构——VirtIO描述符(VirtIO Descriptor)。VirtIO描述符中会包括虚拟设备IO物理地址(GPA，Guest Physical Address)，数据长度，标志位和描述符链中下一个描述符的指针。虚拟机和宿主机都可以通过轮询(同步)或中断(异步)的方式通过Virtqueue进行交互。
有了Virtio，虚拟机就不再需要在每次IO操作时都触发VM_Exit了，显然，IO效率有了质的飞跃。
但是，我们发现，使用VirtIO这种半虚拟化方案，需要在GuestOS中安装前端驱动。如果GuestOS不是Linux这样的开放操作系统，而是Windows操作系统，甚至其他冷门操作系统，会产生定制虚拟化驱动的工作量。
有没有更好的办法，让GuestOS既可以高效地进行IO，又不依赖于特殊的驱动程序呢？
请看下回分解。
