Linux目前支持至少了8种虚拟化系统：
而新的系统也在不断的涌现，各个系统在网络设备、块设备、console及其它设备驱动在新特性支持和性能优化方面存在着瓶颈。
为解决这些问题，Rusty Russell开发了virtio机制，其是一个在hypervisor之上的抽象API接口，让客户机知道自己运行在虚拟化环境中，从而与hypervisor根据virtio标准协作，从而在Guest中达到更好的性能（特别是I/O性能），关于virtio在其论文中如此定义:
前面两文主要对前端网络流的数据路径和虚拟网卡的创建进行了说明，这些可以看做是Guest OS网络数据包收发的准备工作，那么网络数据包是如何在Guest OS中进进出出的呢，本文就是重点讲述Guest OS的数据包的收发路径，其中涉及到一个重要的虚拟化技术，即I/O虚拟化。
上文针对Qemu在前端网络流路径的建立方面做了详细的描述，数据包从Host的物理网卡经过Host Linux内核中的Bridge， 经过Tap设备到达了Qemu的用户态空间。而Qemu是如何把数据包送进Guest中的呢，这里必然要说到到虚拟网卡的建立。
当命令行传入nic相关参数时，Qemu就会解析网络相关的参数后进入虚拟网卡的创建流程。而在上文中提到对于所有-net类型的设备，都视作一个net client来对待。而在net client的建立之前，需要先创建Qemu内部的hub和对应的port，来关联每一个net client，而对于每个创建的-net类型的设备都是可以可以配置其接口的vlan号，从而控制数据包在其中配置的vlan内部进行转发，从而做到多个虚拟设备之间的switch。
KVM在I/O虚拟化方面，传统的方式是使用Qemu纯软件的方式来模拟I/O设备，其中包括经常使用的网卡设备。这次我们重点分析Qemu为实现网络设备虚拟化的全虚拟化方案。本主题从三个组成方面来完整描述，包括：1. 前端网络流的建立； 2. 虚拟网卡的创建； 3. 网络I/O虚拟化 in Guest OS。
本篇主要讲述“前端网络流的建立”。
在“KVM Run Process之Qemu核心流程”一文中讲到Qemu通过KVM_RUN调用KVM提供的API发起KVM的启动，从这里进入到了内核空间运行，本文主要讲述内核中KVM关于VM运行的核心调用流程,所使用的内核版本为linux3.15。