上一期我们探讨了如何将特定外设的中断发送到指定虚拟机的指定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，又不依赖于特殊的驱动程序呢？
请看下回分解。
